Motion candidate list with geometric partition mode coding

ABSTRACT

A visual media processing method includes determining that a first video block of a visual media data uses a geometric partitioning mode (GPM) and a second video block of the visual media data uses a non-GPM mode; constructing, based on a unified pruning process, a first merge list for the first video block and a second merge list for the second video block, wherein the first merge list and the second merge list include merge candidates, and the pruning process includes adding a new merge candidate to the merge list based on comparing motion information of the new merge candidate with motion information of at least one merge candidate in the merge list, wherein the GPM includes splitting the first video block into multiple prediction partitions to apply motion prediction separately, and at least one partition having a non-rectangular shape.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of International Patent ApplicationNo. PCT/CN2020/094305, filed on Jun. 4, 2020, which claims the priorityto and benefit of International Patent Application No.PCT/CN2019/089970, filed on Jun. 4, 2019. All the aforementioned patentapplications are hereby incorporated by reference in their entireties.

TECHNICAL FIELD

This document is related to video and image coding and decodingtechnologies.

BACKGROUND

Digital video accounts for the largest bandwidth use on the internet andother digital communication networks. As the number of connected userdevices capable of receiving and displaying video increases, it isexpected that the bandwidth demand for digital video usage will continueto grow.

SUMMARY

The disclosed techniques may be used by video or image decoder orencoder embodiments to perform coding or decoding of video bitstreamsusing non-rectangular partitioning such as a triangular partitioningmode.

In one example aspect, a method of visual media processing is disclosed.The method includes determining that a first video block of a visualmedia data uses a geometric partitioning mode (GPM) and a second videoblock of the visual media data uses a non-GPM mode; constructing, basedon a unified pruning process, a first merge list for the first videoblock and a second merge list for the second video block, wherein thefirst merge list and the second merge list comprise merge candidates,and the pruning process includes adding a new merge candidate to themerge list based on comparing motion information of the new mergecandidate with motion information of at least one merge candidate in themerge list, wherein the GPM comprises splitting the first video blockinto multiple prediction partitions to apply motion predictionseparately, and at least one partition having a non-rectangular shape.

In another example aspect, another method of visual media processing isdisclosed. The method includes determining, for a conversion between acurrent video block of visual media data and a bitstream representationof the visual media data, initial values of motion informationapplicable to the current video block based on a rule, wherein the rulespecifies checking whether a sub-block based temporal motion vectorpredictor coding (SbTMVP) mode is available for the current video blockbased on a reference list (denoted list X) of a neighboring block of thecurrent video block, where X is an integer and a value of X depends atleast on an encoding condition of the neighboring block; and performingthe conversion based on the determining.

In yet another example aspect, another method of visual media processingis disclosed. The method includes deriving, for a conversion between acurrent video block of a visual media data and a bitstreamrepresentation of the visual media data, one or more collocated motionvectors for one or more sub-blocks of the current video block based on arule, wherein the rule specifies to use a unified derivation process forderiving the one or more collocated motion vectors irrespective of acoding tool used for coding the current video block into the bitstreamrepresentation; and performing the conversion using the merge listcomprising the one or more collocated motion vectors.

In yet another example aspect, another method of visual media processingis disclosed. The method includes identifying one or more conditionsassociated with dimensions of a current video block of visual mediadata, wherein an intra block copy (IBC) mode is applied to the currentvideo block determining, based on whether the one or more conditionsassociated with the dimensions of the current video block are met, amotion candidate list construction process of a motion candidate listfor the current video block, and performing a conversion between thecurrent video block and a bitstream representation of the current videoblock based on the motion candidate list.

In yet another example aspect, another method of visual media processingis disclosed. The method includes making a determination, for aconversion between a current video block of a visual media data and abitstream representation of the visual media data, that a codingtechnique is disabled for the conversion, wherein the bitstreamrepresentation is configured to include a field indicating that amaximum number of merge candidates for the coding technique is zero; andperforming the conversion based on the determination that the codingtechnique is disabled.

In yet another example aspect, another method of visual media processingis disclosed. The method includes making a determination, for aconversion between a current video block and a bitstream representationof the current video block using a rule specifying that a first syntaxelement in the bitstream representation is conditionally included basedon a second syntax element in the bitstream representation indicative ofa maximum number of merge candidates associated with at least one codingtechnique applied to the current video block; and performing theconversion between the current video block and a bitstreamrepresentation of the current video block based on the determination.

In another example aspect, the above-described methods may beimplemented by a video decoder apparatus that comprises a processor.

In another example aspect, the above-described methods may beimplemented by a video encoder apparatus that comprises a processor.

In yet another example aspect, these methods may be embodied in the formof processor-executable instructions and stored on a computer-readableprogram medium.

These, and other, aspects are further described in the present document.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a derivation process for merge candidate list construction.

FIG. 2 shows an example of positions of spatial merge candidates.

FIG. 3 shows an example of candidate pairs considered for redundancycheck of spatial merge candidates.

FIG. 4 shows an example positions for the second prediction unit (PU) ofN×2N and 2N×N partitions.

FIG. 5 shows examples of illustration of motion vector scaling fortemporal merge candidate.

FIG. 6 shows an example of candidate positions for temporal mergecandidate, C0 and C1.

FIG. 7 shows example of combined bi-predictive merge candidate.

FIG. 8 shows examples of derivation process for motion vector predictioncandidates.

FIG. 9 shows an example illustration of motion vector scaling forspatial motion vector candidate.

FIG. 10 shows an example simplified affine motion model for 4-parameteraffine mode (left) and 6-parameter affine model (right).

FIG. 11 shows an example of affine motion vector field per sub-block.

FIG. 12 shows an example Candidates position for affine merge mode.

FIG. 13 shows an example of Modified merge list construction process.

FIG. 14 shows an example of triangle partition based inter prediction.

FIG. 15 shows an example of a CU applying the 1^(st) weighting factorgroup.

FIG. 16 shows an example of motion vector storage.

FIG. 17 shows an example of ultimate motion vector expression (UMVE)search process.

FIG. 18 shows an example of UMVE search points.

FIG. 19 shows an example of MVD (0, 1) mirrored between list 0 and list1 in DMVR.

FIG. 20 shows MVs that may be checked in one iteration.

FIG. 21 is an example of intra block copy.

FIG. 22 is a block diagram of an example of a video processingapparatus.

FIG. 23 is a flowchart for an example of a video processing method.

FIG. 24 is a block diagram of an example video processing system inwhich disclosed techniques may be implemented.

FIG. 25 is a flowchart for an example of a visual media processingmethod.

FIG. 26 is a flowchart for an example of a visual media processingmethod.

FIG. 27 is a flowchart for an example of a visual media processingmethod.

FIG. 28 is a flowchart for an example of a visual media processingmethod.

FIG. 29 is a flowchart for an example of a visual media processingmethod.

FIG. 30 is a flowchart for an example of a visual media processingmethod.

FIG. 31 is a flowchart for an example of a visual media processingmethod.

DETAILED DESCRIPTION

The present document provides various techniques that can be used by adecoder of image or video bitstreams to improve the quality ofdecompressed or decoded digital video or images. For brevity, the term“video” is used herein to include both a sequence of pictures(traditionally called video) and individual images. Furthermore, a videoencoder may also implement these techniques during the process ofencoding in order to reconstruct decoded frames used for furtherencoding.

Section headings are used in the present document for ease ofunderstanding and do not limit the embodiments and techniques to thecorresponding sections. As such, embodiments from one section can becombined with embodiments from other sections.

1. Brief Summary

This document is related to video coding technologies. Specifically, itis related to merge coding including triangular prediction mode. It maybe applied to the existing video coding standard like HEVC, or thestandard (VersatileVideo Coding) to be finalized. It may be alsoapplicable to future video coding standards or video codec.

2. Initial Discussion

Video coding standards have evolved primarily through the development ofthe well-known ITU-T and ISO/IEC standards. The ITU-T produced H.261 andH.263, ISO/IEC produced MPEG-1 and MPEG-4 Visual, and the twoorganizations jointly produced the H.262/MPEG-2 Video and H.264/MPEG-4Advanced Video Coding (AVC) and H.265/HEVC standards. Since H.262, thevideo coding standards are based on the hybrid video coding structurewherein temporal prediction plus transform coding are utilized. Toexplore the future video coding technologies beyond HEVC, Joint VideoExploration Team (JVET) was founded by VCEG and MPEG jointly in 2015.Since then, many new methods have been adopted by JVET and put into thereference software named Joint Exploration Model (JEM). In April 2018,the Joint Video Expert Team (JVET) between VCEG(Q6/16) and ISO/IEC JTC1SC29/WG11 (MPEG) was created to work on the VVC standard targeting at50% bitrate reduction compared to HEVC.

The latest version of VVC draft, i.e., Versatile Video Coding (Draft 5)could be found at:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/14_Geneva/wg11/JVET-N1001-v7.zip

The latest reference software of VVC, named VTM, could be found at:https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags/VTM-5.0

2.1 Inter Prediction in HEVC/H.265

For inter-coded coding units (CUs), it may be coded with one predictionunit (PU), 2 PUs according to partition mode. Each inter-predicted PUhas motion parameters for one or two reference picture lists. Motionparameters include a motion vector and a reference picture index. Usageof one of the two reference picture lists may also be signalled usinginter_pred_idc. Motion vectors may be explicitly coded as deltasrelative to predictors.

When a CU is coded with skip mode, one PU is associated with the CU, andthere are no significant residual coefficients, no coded motion vectordelta or reference picture index. A merge mode is specified whereby themotion parameters for the current PU are obtained from neighbouring PUs,including spatial and temporal candidates. The merge mode can be appliedto any inter-predicted PU, not only for skip mode. The alternative tomerge mode is the explicit transmission of motion parameters, wheremotion vector (to be more precise, motion vector differences (MVD)compared to a motion vector predictor), corresponding reference pictureindex for each reference picture list and reference picture list usageare signalled explicitly per each PU. Such a mode is named Advancedmotion vector prediction (AMVP) in this disclosure.

When signalling indicates that one of the two reference picture lists isto be used, the PU is produced from one block of samples. This isreferred to as ‘uni-prediction’. Uni-prediction is available both forP-slices and B-slices.

When signalling indicates that both of the reference picture lists areto be used, the PU is produced from two blocks of samples. This isreferred to as ‘bi-prediction’. Bi-prediction is available for B-slicesonly.

The following text provides the details on the inter prediction modesspecified in HEVC. The description will start with the merge mode.

2.1.1 Reference Picture List

In HEVC, the term inter prediction is used to denote prediction derivedfrom data elements (e.g., sample values or motion vectors) of referencepictures other than the current decoded picture. Like in H.264/AVC, apicture can be predicted from multiple reference pictures. The referencepictures that are used for inter prediction are organized in one or morereference picture lists. The reference index identifies which of thereference pictures in the list should be used for creating theprediction signal.

A single reference picture list, List 0, is used for a P slice and tworeference picture lists, List 0 and List 1 are used for B slices. Itshould be noted reference pictures included in List 0/1 could be frompast and future pictures in terms of capturing/display order.

2.1.2 Merge Mode

2.1.2.1 Derivation of Candidates for Merge Mode

When a PU is predicted using merge mode, an index pointing to an entryin the merge candidates list is parsed from the bitstream and used toretrieve the motion information. The construction of this list isspecified in the HEVC standard and can be summarized according to thefollowing sequence of steps:

-   -   Step 1: Initial candidates derivation        -   Step 1.1: Spatial candidates derivation        -   Step 1.2: Redundancy check for spatial candidates        -   Step 1.3: Temporal candidates derivation    -   Step 2: Additional candidates insertion        -   Step 2.1: Creation of bi-predictive candidates        -   Step 2.2: Insertion of zero motion candidates

These steps are also schematically depicted in FIG. 1. For spatial mergecandidate derivation, a maximum of four merge candidates are selectedamong candidates that are located in five different positions. Fortemporal merge candidate derivation, a maximum of one merge candidate isselected among two candidates. Since constant number of candidates foreach PU is assumed at decoder, additional candidates are generated whenthe number of candidates obtained from step 1 does not reach the maximumnumber of merge candidate (MaxNumMergeCand) which is signalled in sliceheader. Since the number of candidates is constant, index of best mergecandidate is encoded using truncated unary binarization (TU). If thesize of CU is equal to 8, all the PUs of the current CU share a singlemerge candidate list, which is identical to the merge candidate list ofthe 2N×2N prediction unit.

In the following, the operations associated with the aforementionedsteps are detailed.

2.1.2.2 Spatial Candidates Derivation

In the derivation of spatial merge candidates, a maximum of four mergecandidates are selected among candidates located in the positionsdepicted in FIG. 2. The order of derivation is A₁, B₁, B₀, A₀ and B₂.Position B₂ is considered only when any PU of position A₁, B₁, B₀, A₀ isnot available (e.g. because it belongs to another slice or tile) or isintra coded. After candidate at position A₁ is added, the addition ofthe remaining candidates is subject to a redundancy check which ensuresthat candidates with same motion information are excluded from the listso that coding efficiency is improved. To reduce computationalcomplexity, not all possible candidate pairs are considered in thementioned redundancy check. Instead only the pairs linked with an arrowin FIG. 3 are considered and a candidate is only added to the list ifthe corresponding candidate used for redundancy check has not the samemotion information. Another source of duplicate motion information isthe “second PU” associated with partitions different from 2N×2N. As anexample, FIG. 4 depicts the second PU for the case of N×2N and 2N×N,respectively. When the current PU is partitioned as N×2N, candidate atposition A₁ is not considered for list construction. In fact, by addingthis candidate will lead to two prediction units having the same motioninformation, which is redundant to just have one PU in a coding unit.Similarly, position B₁ is not considered when the current PU ispartitioned as 2N×N.

2.1.2.3 Temporal Candidates Derivation

In this step, only one candidate is added to the list. Particularly, inthe derivation of this temporal merge candidate, a scaled motion vectoris derived based on co-located PU in a co-located picture. The scaledmotion vector for temporal merge candidate is obtained as illustrated bythe dotted line in FIG. 5, which is scaled from the motion vector of theco-located PU using the POC distances, tb and td, where tb is defined tobe the POC difference between the reference picture of the currentpicture and the current picture and td is defined to be the POCdifference between the reference picture of the co-located picture andthe co-located picture. The reference picture index of temporal mergecandidate is set equal to zero. A practical realization of the scalingprocess is described in the HEVC specification. For a B-slice, twomotion vectors, one is for reference picture list 0 and the other is forreference picture list 1, are obtained and combined to make thebi-predictive merge candidate.

2.1.2.4 Co-Located Picture and Co-Located PU

When TMVP is enabled (i.e., slice temporal_mvp_enabled_flag is equal to1), the variable ColPic representing the col-located picture is derivedas follows:

-   -   If current slice is B slice and the signalled        collocated_from_l0_flag is equal to 0, ColPic is set equal to        RefPicList1[collocated_ref_idx].    -   Otherwise (slice_type is equal to B and collocated_from_l0_flag        is equal to 1, or slice_type is equal to P), ColPic is set equal        to RefPicList0[collocated_ref_idx].        wherein collocated_ref_idx and collocated_from_l0_flag are two        syntax elements which may be signalled in slice header.

In the co-located PU (Y) belonging to the reference frame, the positionfor the temporal candidate is selected between candidates C₀ and C₁, asdepicted in FIG. 6. If PU at position C₀ is not available, is intracoded, or is outside of the current coding tree unit (CTU aka. LCU,largest coding unit) row, position C₁ is used. Otherwise, position C₀ isused in the derivation of the temporal merge candidate.

Related syntax elements are described as follows:

7.3.6.1 General Slice Segment Header Syntax

Descriptor slice_segment_header( ) { first_slice_segment_in_pic_flagu(1) ... if( slice_type = = P | | slice_type = = B ) {num_ref_idx_active_override_flag u(1) if(num_ref_idx_active_override_flag ) { num_ref_idx_10_active_minus1 ue(v)if( slice_type = = B ) num_ref_idx_l1_active_minus1 ue(v) } ...

u(1)

ue(v)

... byte_alignment( ) }2.1.2.5 Derivation of MVs for the TMVP Candidate

More specifically, the following steps are performed in order to derivethe TMVP candidate:

-   -   1) set reference picture list X=0, target reference picture to        be the reference picture with index equal to 0 (i.e., curr_ref)        in list X. Invoke the derivation process for collocated motion        vectors to get the MV for list X pointing to curr_ref.    -   2) if current slice is B slice, set reference picture list X=1,        target reference picture to be the reference picture with index        equal to 0 (i.e., curr_ref) in list X. Invoke the derivation        process for collocated motion vectors to get the MV for list X        pointing to curr_ref.

The derivation process for collocated motion vectors is described in thenext sub-section 2.1.2.5.1.

2.1.2.5.1 Derivation Process for Collocated Motion Vectors

For the co-located block, it may be intra or inter coded withuni-prediction or bi-prediction. If it is intra coded, TMVP candidate isset to be unavailable.

If it is uni-prediction from list A, the motion vector of list A isscaled to the target reference picture list X.

If it is bi-prediction and the target reference picture list is X, themotion vector of list A is scaled to the target reference picture listX, and A is determined according to the following rules:

-   -   If none of reference pictures has a greater POC values compared        to current picture, A is set equal to X.    -   Otherwise, A is set equal to collocated_from_l0_flag.

The related working draft in JCTVC-W1005-v4 is described as follows:

8.5.3.2.9 Derivation Process for Collocated Motion Vectors

Inputs to this process are:

-   -   a variable currPb specifying the current prediction block,    -   a variable colPb specifying the collocated prediction block        inside the collocated picture specified by ColPic,    -   a luma location (xColPb, yColPb) specifying the top-left sample        of the collocated luma prediction block specified by colPb        relative to the top-left luma sample of the collocated picture        specified by ColPic,    -   a reference index refIdxLX, with X being 0 or 1.

Outputs of this process are:

-   -   the motion vector prediction mvLXCol,    -   the availability flag availableFlagLXCol.

The variable currPic specifies the current picture.

The arrays predFlagL0Col[x][y], mvL0Col[x][y], and refIdxL0Col[x][y] areset equal to PredFlagL0[x][y], MvL0[x][y], and RefIdxL0[x][y],respectively, of the collocated picture specified by ColPic, and thearrays predFlagL1Col[x][y], mvL1Col[x][y], and refIdxL1Col[x][y] are setequal to PredFlagL1[x][y], MvL1[x][y], and RefIdxL1[x][y], respectively,of the collocated picture specified by ColPic.

The variables mvLXCol and availableFlagLXCol are derived as follows:

-   -   If colPb is coded in an intra prediction mode, both components        of mvLXCol are set equal to 0 and availableFlagLXCol is set        equal to 0.    -   Otherwise, the motion vector mvCol, the reference index        refIdxCol, and the reference list identifier listCol are derived        as follows:        -   If predFlagL0Col[xColPb][yColPb] is equal to 0, mvCol,            refIdxCol, and listCol are set equal to            mvL1Col[xColPb][yColPb], refIdxL1Col[xColPb][yColPb], and            L1, respectively.        -   Otherwise, if predFlagL0Col[xColPb][yColPb] is equal to 1            and predFlagL1Col[xColPb][yColPb] is equal to 0, mvCol,            refIdxCol, and listCol are set equal to            mvL0Col[xColPb][yColPb], refIdxL0Col[xColPb][yColPb], and            L0, respectively.        -   Otherwise (predFlagL0Col[xColPb][yColPb] is equal to 1 and            predFlagL1Col[xColPb][yColPb] is equal to 1), the following            assignments are made:            -   If NoBackwardPredFlag is equal to 1, mvCol, refIdxCol,                and listCol are set equal to mvLXCol[xColPb][yColPb],                refIdxLXCol[xColPb][yColPb], and LX, respectively.            -   Otherwise, mvCol, refIdxCol, and listCol are set equal                to mvLNCol[xColPb][yColPb], refIdxLNCol[xColPb][yColPb],                and LN, respectively, with N being the value of                collocated_from_l0_flag.    -   and mvLXCol and availableFlagLXCol are derived as follows:        -   If LongTermRefPic(currPic, currPb, refIdxLX, LX) is not            equal to LongTermRefPic(ColPic, colPb, refIdxCol, listCol),            both components of mvLXCol are set equal to 0 and            availableFlagLXCol is set equal to 0.        -   Otherwise, the variable availableFlagLXCol is set equal to            1, refPicListCol[refIdxCol] is set to be the picture with            reference index refIdxCol in the reference picture list            listCol of the slice containing prediction block colPb in            the collocated picture specified by ColPic, and the            following applies:            colPocDiff=DiffPicOrderCnt(ColPic,refPicListCol[refIdxCol])  (2-1)            currPocDiff=DiffPicOrderCnt(currPic,RefPicListX[refIdxLX])  (2-2)            -   If RefPicListX[refIdxLX] is a long-term reference                picture, or colPocDiff is equal to currPocDiff, mvLXCol                is derived as follows:                mvLXCol=mvCol  (2-3)            -   Otherwise, mvLXCol is derived as a scaled version of the                motion vector mvCol as follows:                tx=(16384+(Abs(td)>>1))/td  (2-4)                distScaleFactor=Clip3(−4096,4095,(tb*tx+32)>>6)  (2-5)                mvLXCol=Clip3(−32768,32767,Sign(distScaleFactor*mvCol)*((Abs(distScaleFactor*mvCol)+127)>>8))  (2-6)            -   where td and tb are derived as follows:                td=Clip3(−128,127,colPocDiff)  (2-7)                tb=Clip3(−128,127,currPocDiff)  (2-8)

Definition of NoBackwardPredFlag is:

The variable NoBackwardPredFlag is derived as follows:

-   -   If DiffPicOrderCnt(aPic, CurrPic) is less than or equal to 0 for        each picture aPic in RefPicList0 or RefPicList1 of the current        slice, NoBackwardPredFlag is set equal to 1.    -   Otherwise, NoBackwardPredFlag is set equal to 0.        2.1.2.6 Additional Candidates Insertion

Besides spatial and temporal merge candidates, there are two additionaltypes of merge candidates: combined bi-predictive merge candidate andzero merge candidate. Combined bi-predictive merge candidates aregenerated by utilizing spatial and temporal merge candidates. Combinedbi-predictive merge candidate is used for B-Slice only. The combinedbi-predictive candidates are generated by combining the first referencepicture list motion parameters of an initial candidate with the secondreference picture list motion parameters of another. If these two tuplesprovide different motion hypotheses, they will form a new bi-predictivecandidate. As an example, FIG. 7 depicts the case when two candidates inthe original list (on the left), which have mvL0 and refIdxL0 or mvL1and refIdxL1, are used to create a combined bi-predictive mergecandidate added to the final list (on the right). There are numerousrules regarding the combinations which are considered to generate theseadditional merge candidates.

Zero motion candidates are inserted to fill the remaining entries in themerge candidates list and therefore hit the MaxNumMergeCand capacity.These candidates have zero spatial displacement and a reference pictureindex which starts from zero and increases every time a new zero motioncandidate is added to the list. Finally, no redundancy check isperformed on these candidates.

2.1.3 AMVP

AMVP exploits spatio-temporal correlation of motion vector withneighbouring PUs, which is used for explicit transmission of motionparameters. For each reference picture list, a motion vector candidatelist is constructed by firstly checking availability of left, abovetemporally neighbouring PU positions, removing redundant candidates andadding zero vector to make the candidate list to be constant length.Then, the encoder can select the best predictor from the candidate listand transmit the corresponding index indicating the chosen candidate.Similarly with merge index signalling, the index of the best motionvector candidate is encoded using truncated unary. The maximum value tobe encoded in this case is 2 (see FIG. 8). In the following sections,details about derivation process of motion vector prediction candidateare provided.

2.1.3.1 Derivation of AMVP Candidates

FIG. 8 summarizes derivation process for motion vector predictioncandidate.

In motion vector prediction, two types of motion vector candidates areconsidered: spatial motion vector candidate and temporal motion vectorcandidate. For spatial motion vector candidate derivation, two motionvector candidates are eventually derived based on motion vectors of eachPU located in five different positions as depicted in FIG. 2.

For temporal motion vector candidate derivation, one motion vectorcandidate is selected from two candidates, which are derived based ontwo different co-located positions. After the first list ofspatio-temporal candidates is made, duplicated motion vector candidatesin the list are removed. If the number of potential candidates is largerthan two, motion vector candidates whose reference picture index withinthe associated reference picture list is larger than 1 are removed fromthe list. If the number of spatio-temporal motion vector candidates issmaller than two, additional zero motion vector candidates is added tothe list.

2.1.3.2 Spatial Motion Vector Candidates

In the derivation of spatial motion vector candidates, a maximum of twocandidates are considered among five potential candidates, which arederived from PUs located in positions as depicted in FIG. 2, thosepositions being the same as those of motion merge. The order ofderivation for the left side of the current PU is defined as A₀, A₁, andscaled A₀, scaled A₁. The order of derivation for the above side of thecurrent PU is defined as B₀, B₁, B₂, scaled B₀, scaled B₁, scaled B₂.For each side there are therefore four cases that can be used as motionvector candidate, with two cases not required to use spatial scaling,and two cases where spatial scaling is used. The four different casesare summarized as follows.

-   -   No spatial scaling        -   (1) Same reference picture list, and same reference picture            index (same POC)        -   (2) Different reference picture list, but same reference            picture (same POC)    -   Spatial scaling        -   (3) Same reference picture list, but different reference            picture (different POC)        -   (4) Different reference picture list, and different            reference picture (different POC)

The no-spatial-scaling cases are checked first followed by the spatialscaling. Spatial scaling is considered when the POC is different betweenthe reference picture of the neighbouring PU and that of the current PUregardless of reference picture list. If all PUs of left candidates arenot available or are intra coded, scaling for the above motion vector isallowed to help parallel derivation of left and above MV candidates.Otherwise, spatial scaling is not allowed for the above motion vector.

In a spatial scaling process, the motion vector of the neighbouring PUis scaled in a similar manner as for temporal scaling, as depicted asFIG. 9. The main difference is that the reference picture list and indexof current PU is given as input; the actual scaling process is the sameas that of temporal scaling.

2.1.3.3 Temporal Motion Vector Candidates

Apart for the reference picture index derivation, all processes for thederivation of temporal merge candidates are the same as for thederivation of spatial motion vector candidates (see FIG. 6). Thereference picture index is signalled to the decoder.

2.2 Inter Prediction Methods in VVC

There are several new coding tools for inter prediction improvement,such as Adaptive Motion Vector difference Resolution (AMVR) forsignaling MVD, Merge with Motion Vector Differences (MMVD), Triangularprediction mode (TPM), Combined intra-inter prediction (CIIP), AdvancedTMVP (ATMVP, aka SbTMVP), affine prediction mode, GeneralizedBi-Prediction (GBI), Decoder-side Motion Vector Refinement (DMVR) andBi-directional Optical flow (BIO, a.k.a BDOF).

There are three different merge list construction processes supported inVVC:

-   -   1) Sub-block merge candidate list: it includes ATMVP and affine        merge candidates. One merge list construction process is shared        for both affine modes and ATMVP mode. Here, the ATMVP and affine        merge candidates may be added in order. Sub-block merge list        size is signaled in slice header, and maximum value is 5.    -   2) Regular merge list: For inter-coded blocks, one merge list        construction process is shared. Here, the spatial/temporal merge        candidates, HMVP, pairwise merge candidates and zero motion        candidates may be inserted in order. Regular merge list size is        signaled in slice header, and maximum value is 6. MMVD, TPM,        CIIP rely on the regular merge list.    -   3) IBC merge list: it is done in a similar way as the regular        merge list.

Similarly, there are three AMVP lists supported in VVC:

-   -   1) Affine AMVP candidate list    -   2) Regular AMVP candidate list    -   3) IBC AMVP candidate list: the same construction process as the        IBC merge list due to the adoption of JVET-N0843        2.2.1 Coding Block Structure in VVC

In VVC, a Quad-Tree/Binary Tree/Ternary-Tree (QT/BT/TT) structure isadopted to divide a picture into square or rectangle blocks.

Besides QT/BT/TT, separate tree (a.k.a. Dual coding tree) is alsoadopted in VVC for I-frames. With separate tree, the coding blockstructure are signaled separately for the luma and chroma components.

In addition, the CU is set equal to PU and TU, except for blocks codedwith a couple of specific coding methods (such as intra sub-partitionprediction wherein PU is equal to TU, but smaller than CU, and sub-blocktransform for inter-coded blocks wherein PU is equal to CU, but TU issmaller than PU).

2.2.2 Affine Prediction Mode

In HEVC, only translation motion model is applied for motioncompensation prediction (MCP). While in the real world, there are manykinds of motion, e.g. zoom in/out, rotation, perspective motions and theother irregular motions. In VVC, a simplified affine transform motioncompensation prediction is applied with 4-parameter affine model and6-parameter affine model. As shown FIG. 10, the affine motion field ofthe block is described by two control point motion vectors (CPMVs) forthe 4-parameter affine model and 3 CPMVs for the 6-parameter affinemodel.

The motion vector field (MVF) of a block is described by the followingequations with the 4-parameter affine model (wherein the 4-parameter aredefined as the variables a, b, e and f) in equation (1) and 6-parameteraffine model (wherein the 4-parameter are defined as the variables a, b,c, d, e and f) in equation (2) respectively:

$\begin{matrix}\left\{ \begin{matrix}{{m\;{v^{h}\left( {x,y} \right)}} = {{{a\; x} - {b\; y} + e} = {{\frac{\left( {{mv_{1}^{h}} - {mv_{0}^{h}}} \right)}{w}x} - {\frac{\left( {{mv_{1}^{v}} - {mv_{0}^{v}}} \right)}{w}y} + {mv_{0}^{h}}}}} \\{{m{v^{v}\left( {x,y} \right)}} = {{{b\; x} + {a\; y} + f} = {{\frac{\left( {{mv_{1}^{v}} - {mv_{0}^{v}}} \right)}{w}x} + {\frac{\left( {{mv_{1}^{h}} - {mv_{0}^{h}}} \right)}{w}y} + {mv_{0}^{v}}}}}\end{matrix} \right. & (1) \\\left\{ \begin{matrix}{{m{v^{h}\left( {x,y} \right)}} = {{{ax} + {cy} + e} = {{\frac{\left( {{mv_{1}^{h}} - {mv_{0}^{h}}} \right)}{w}x} + {\frac{\left( {{mv_{2}^{h}} - {mv_{0}^{h}}} \right)}{h}y} + {mv_{0}^{h}}}}} \\{{m{v^{v}\left( {x,y} \right)}} = {{{b\; x} + {d\; y} + f} = {{\frac{\left( {{mv_{1}^{v}} - {mv_{0}^{v}}} \right)}{w}x} + {\frac{\left( {{mv_{2}^{v}} - {mv_{0}^{v}}} \right)}{h}y} + {mv_{0}^{v}}}}}\end{matrix} \right. & (2)\end{matrix}$where (mv^(h) ₀, mv^(h) ₀) is motion vector of the top-left cornercontrol point, and (mv^(h) ₁, mv^(h) ₁) is motion vector of thetop-right corner control point and (mv^(h) ₂, mv^(h) ₂) is motion vectorof the bottom-left corner control point, all of the three motion vectorsare called control point motion vectors (CPMV), (x, y) represents thecoordinate of a representative point relative to the top-left samplewithin current block and (mv^(h)(x,y), mv^(v)(x,y)) is the motion vectorderived for a sample located at (x, y). The CP motion vectors may besignaled (like in the affine AMVP mode) or derived on-the-fly (like inthe affine merge mode). w and h are the width and height of the currentblock. In practice, the division is implemented by right-shift with arounding operation. In VTM, the representative point is defined to bethe center position of a sub-block, e.g., when the coordinate of theleft-top corner of a sub-block relative to the top-left sample withincurrent block is (xs, ys), the coordinate of the representative point isdefined to be (xs+2, ys+2). For each sub-block (i.e., 4×4 in VTM), therepresentative point is utilized to derive the motion vector for thewhole sub-block.

In order to further simplify the motion compensation prediction,sub-block based affine transform prediction is applied. To derive motionvector of each M×N (both M and N are set to 4 in current VVC) sub-block,the motion vector of the center sample of each sub-block, as shown inFIG. 11, is calculated according to Equation (1) and (2), and rounded to1/16 fraction accuracy. Then the motion compensation interpolationfilters for 1/16-pel are applied to generate the prediction of eachsub-block with derived motion vector. The interpolation filters for1/16-pel are introduced by the affine mode.

After MCP, the high accuracy motion vector of each sub-block is roundedand saved as the same accuracy as the normal motion vector.

2.2.3 MERGE for Whole Block

2.2.3.1 Merge List Construction of Translational Regular Merge Mode

2.2.3.1.1 History-Based Motion Vector Prediction (HMVP)

Different from the merge list design, in VVC, the history-based motionvector prediction (HMVP) method is employed.

In HMVP, the previously coded motion information is stored. The motioninformation of a previously coded block is defined as an HMVP candidate.Multiple HMVP candidates are stored in a table, named as the HMVP table,and this table is maintained during the encoding/decoding processon-the-fly. The HMVP table is emptied when starting coding/decoding anew tile/LCU row/a slice. Whenever there is an inter-coded block andnon-sub-block, non-TPM mode, the associated motion information is addedto the last entry of the table as a new HMVP candidate. The overallcoding flow is depicted in FIG. 12.

2.2.3.1.2 Regular Merge List Construction Process

The construction of the regular merge list (for translational motion)can be summarized according to the following sequence of steps:

-   -   Step 1: Derivation of spatial candidates    -   Step 2: Insertion of HMVP candidates    -   Step 3: Insertion of pairwise average candidates    -   Step 4: default motion candidates

HMVP candidates could be used in both AMVP and merge candidate listconstruction processes. FIG. 13 depicts the modified merge candidatelist construction process (shown using dotted boxes). When the mergecandidate list is not full after the TMVP candidate insertion, HMVPcandidates stored in the HMVP table could be utilized to fill in themerge candidate list. Considering that one block usually has a highercorrelation with the nearest neighbouring block in terms of motioninformation, the HMVP candidates in the table are inserted in adescending order of indices. The last entry in the table is firstlyadded to the list, while the first entry is added in the end. Similarly,redundancy removal is applied on the HMVP candidates. Once the totalnumber of available merge candidates reaches the maximal number of mergecandidates allowed to be signaled, the merge candidate list constructionprocess is terminated.

It is noted that all the spatial/temporal/HMVP candidate shall be codedwith non-IBC mode. Otherwise, it is not allowed to be added to theregular merge candidate list.

HMVP table contains up to 5 regular motion candidates and each of themis unique.

2.2.3.1.2.1 Pruning Processes

A candidate is only added to the list if the corresponding candidateused for redundancy check has not the same motion information. Suchcomparison process is called pruning process.

The pruning process among the spatial candidates is dependent on theusage of TPM for current block.

When current block is coded without TPM mode (e.g., regular merge, MMVD,CIIP), the HEVC pruning process (i.e., five pruning) for the spatialmerge candidates is utilized.

2.2.4 Triangular Prediction Mode (TPM)

In VVC, a triangle partition mode is supported for inter prediction. Thetriangle partition mode is only applied to CUs that are 8×8 or largerand are coded in merge mode but not in MMVD or CIIP mode. For a CUsatisfying these conditions, a CU-level flag is signalled to indicatewhether the triangle partition mode is applied or not.

When this mode is used, a CU is split evenly into two triangle-shapedpartitions, using either the diagonal split or the anti-diagonal split,as depicted in FIG. 14. Each triangle partition in the CU isinter-predicted using its own motion; only uni-prediction is allowed foreach partition, that is, each partition has one motion vector and onereference index. The uni-prediction motion constraint is applied toensure that same as the conventional bi-prediction, only two motioncompensated prediction are needed for each CU.

If the CU-level flag indicates that the current CU is coded using thetriangle partition mode, a flag indicating the direction of the trianglepartition (diagonal or anti-diagonal), and two merge indices (one foreach partition) are further signalled. After predicting each of thetriangle partitions, the sample values along the diagonal oranti-diagonal edge are adjusted using a blending processing withadaptive weights. This is the prediction signal for the whole CU andtransform and quantization process will be applied to the whole CU as inother prediction modes. Finally, the motion field of a CU predictedusing the triangle partition mode is stored in 4×4 units.

The regular merge candidate list is re-used for triangle partition mergeprediction with no extra motion vector pruning. For each merge candidatein the regular merge candidate list, one and only one of its L0 or L1motion vector is used for triangle prediction. In addition, the order ofselecting the L0 vs. L1 motion vector is based on its merge indexparity. With this scheme, the regular merge list can be directly used.

2.2.4.1 Merge List Construction Process for TPM

Basically, the regular merge list construction process is applied asproposed in JVET-N0340. However, some modifications are added.

Specifically, the followings are applied:

-   -   1) How to do the pruning process is dependent on the usage of        TPM for current block        -   If the current block is not coded with TPM, the HEVC 5            pruning applied to spatial merge candidates is invoked        -   Otherwise (if the current block is coded with TPM), full            pruning is applied when adding a new spatial merge            candidates. That is, B1 is compared to A1; B0 is compared to            A1 and B1; A0 is compared to A1, B1, and B0; B2 is compared            to A1, B1, A0, and B0.    -   2) The condition on whether to check of motion information from        B2 is dependent on the usage of TPM for current block        -   If the current block is not coded with TPM, B2 is accessed            and checked only when there are less than 4 spatial merge            candidates before checking B2.        -   Otherwise (if the current block is coded with TPM), B2 is            always accessed and checked regardless how many available            spatial merge candidates before adding B2.            2.2.4.2 Adaptive Weighting Process

After predicting each triangular prediction unit, an adaptive weightingprocess is applied to the diagonal edge between the two triangularprediction units to derive the final prediction for the whole CU. Twoweighting factor groups are defined as follows:

-   -   1^(st) weighting factor group: {⅞, 6/8, 4/8, 2/8, ⅛} and {⅞,        4/8, ⅛} are used for the luminance and the chrominance samples,        respectively;    -   2^(nd) weighting factor group: {⅞, 6/8, ⅝, 4/8, ⅜, 2/8, ⅛} and {        6/8, 4/8, 2/8} are used for the luminance and the chrominance        samples, respectively.

Weighting factor group is selected based on the comparison of the motionvectors of two triangular prediction units. The 2^(nd) weighting factorgroup is used when any one of the following condition is true:

-   -   the reference pictures of the two triangular prediction units        are different from each other    -   absolute value of the difference of two motion vectors'        horizontal values is larger than 16 pixels.    -   absolute value of the difference of two motion vectors' vertical        values is larger than 16 pixels.

Otherwise, the 1^(st) weighting factor group is used. An example isshown in FIG. 15.

2.2.4.3 Motion Vector Storage

The motion vectors (Mv1 and Mv2 in FIG. 16) of the triangular predictionunits are stored in 4×4 grids. For each 4×4 grid, either uni-predictionor bi-prediction motion vector is stored depending on the position ofthe 4×4 grid in the CU. As shown in FIG. 16, uni-prediction motionvector, either Mv1 or Mv2, is stored for the 4×4 grid located in thenon-weighted area (that is, not located at the diagonal edge). On theother hand, a bi-prediction motion vector is stored for the 4×4 gridlocated in the weighted area. The bi-prediction motion vector is derivedfrom Mv1 and Mv2 according to the following rules:

-   -   1) In the case that Mv1 and Mv2 have motion vector from        different directions (L0 or L1), Mv1 and Mv2 are simply combined        to form the bi-prediction motion vector.    -   2) In the case that both Mv1 and Mv2 are from the same L0 (or        L1) direction,        -   If the reference picture of Mv2 is the same as a picture in            the L1 (or L0) reference picture list, Mv2 is scaled to the            picture. Mv1 and the scaled Mv2 are combined to form the            bi-prediction motion vector.        -   If the reference picture of M is the same as a picture in            the L1 (or L0) reference picture list, Mv1 is scaled to the            picture. The scaled Mv1 and Mv2 are combined to form the            bi-prediction motion vector.        -   Otherwise, only Mv1 is stored for the weighted area.            2.2.4.4 Syntax Tables, Semantics and Decoding Process for            Merge Mode            7.3.5.1 General Slice Header Syntax

Descriptor slice_header( ) { slice_pic_parameter_set_id ue(v) if(rect_slice_flag | | NumBricksInPic > 1 ) slice_address u(v) if(!rect_slice_flag && !single_brick_per_slice_flag )num_bricks_in_slice_minus1 ue(v) slice_type ue(v) ...

if( sps_temporal_mvp_enabled_flag ) slice_temporal_mvp_enabled_flag u(1)if( slice_type = = B ) mvd_l1_zero_flag u(1) if( cabac_init_present_flag) cabac_init_flag u(1) if( slice_temporal_mvp_enabled_flag ) { if(slice_type = = B ) collocated_from_l0_flag u(1) } if( (weighted_pred_flag && slice_type = = P ) | | ( weighted_bipred_flag &&slice_type = = B ) ) pred_weight_table( )

ue(v)

ue(v)

u(1)

ue(v) } else if ( sps_ibc_enabled_flag ) six_minus_max_num_merge_candue(v) slice_qp_delta se(v) if( pps_slice_chroma_qp_offsets_present_flag) { slice_cb_qp_offset se(v) slice_cr_qp_offset se(v) } ...byte_alignment( ) }7.3.7.5 Coding Unit Syntax

Descriptor coding_unit( x0,y0,cbWidth,cbHeight,treeType ) { if(slice_type != I | | sps_ibc_enabled_flag ) { if( treeType !=DUAL_TREE_CHROMA && !( cbWidth = = 4 && cbHeight = = 4 &&!sps_ibc_enabled_flag ) ) cu_skip_flag[ x0 ][ y0 ] ae(v) if(cu_skip_flag[ x0 ][ y0 ] = = 0 && slice_type != I && !( cbWidth = = 4 &&cbHeight = = 4 ) ) pred_mode_flag ae(v) if( ( ( slice_type = = I &&cu_skip_flag[ x0 ][ y0 ] = = 0 ) | | ( slice_type != I && ( CuPredMode[x0 ][ y0 ] != MODE_INTRA | | ( cbWidth = = 4 && cbHeight = = 4 &&cu_skip_flag[ x0 ][ y0 ] = = 0 ) ) ) ) && sps_ibc_enabled_flag && (cbWidth != 128 | | cbHeight!= 128 ) ) pred_mode_ibc_flag ae(v) } if(CuPredMode[ x0 ][ y0 ] = = MODE_INTRA ) { ... } } else if( treeType !=DUAL_TREE_CHROMA ) { /* MODE_INTER or MODE_IBC */ if( cu_skip_flag[ x0][ y0 ] = = 0 ) general_merge_flag[ x0 ][ y0 ] ae(v) if(general_merge_flag[ x0 ][ y0 ] ) { merge_data( x0,y0,cbWidth,cbHeight )

ae(v)

ae(v)

} else { if( slice_type == B ) inter_pred_idc[ x0 ][ y0 ] ae(v) if(sps_affine_enabled_flag && cbWidth >= 16 && cbHeight >= 16 ) {inter_affine_flag[ x0 ][ y0 ] ae(v) if( sps_affine_type_flag &&inter_affine_flag[ x0 ][ y0 ] ) cu_affine_type_flag[ x0 ][ y0 ] ae(v) }if( sps_smvd_enabled_flag && inter_pred_idc[ x0 ][ y0 ] = = PRED_BI &&!inter_affine_flag[ x0 ][ y0 ] && RefIdxSymL0 > − 1 && RefIdxSymL1 > − 1) sym_mvd_flag[ x0 ][ y0 ] ae(v) ... } }7.3.7.7 Merge Data Syntax

Descriptor merge_data(x0,y0,cbWidth,cbHeight ) {

ae(v)

if( sps_mmvd_enabled_flag | | cbWidth * cbHeight != 32 )regular_merge_flag[ x0 ][ y0 ] ae(v) if ( regular_merge_flag[ x0 ][ y0 ]= = 1 ){ if( MaxNumMergeCand > 1 ) merge_idx[ x0 ][ y0 ] ae(v) } else {if( sps_mmvd_enabled_flag && cbWidth * cbHeight != 32 ) mmvd_merge_flag[x0 ][ y0 ] ae(v) if( mmvd_merge_flag[ x0 ][ y0 ] = = 1 ) { if(MaxNumMergeCand > 1 ) mmvd_cand_flag[ x0 ][ y0 ] ae(v)mmvd_distance_idx[ x0 ][ y0 ] ae(v) mmvd_direction_idx[ x0 ][ y0 ] ae(v)} else { if( MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >=8 ) merge_subblock_flag[ x0 ][ y0 ] ae(v) if( merge_subblock_flag[ x0 ][y0 ] = = 1 ) { if( MaxNumSubblockMergeCand > 1 ) merge_subblock_idx[ x0][y0 ] ae(v) } else { if( sps_ciip_enabled_flag && cu_skip_flag[ x0 ][y0 ] = = 0 && ( cbWidth * cbHeight ) >= 64 && cbWidth < 128 && cbHeight< 128 ) { ciip_flag[ x0 ][ y0 ] ae(v) if( ciip_flag[ x0 ][ y0 ] &&MaxNumMergeCand > 1 ) merge_idx[ x0 ][ y0 ] ae(v) } if(MergeTriangleFlag[ x0 ][ y0 ] ) { merge_triangle_split_dir[ x0 ][ y0 ]ae(v) merge_triangle_idx0[ x0 ][ y0 ] ae(v) merge_triangle_idx1[ x0 ][y0 ] ae(v) } } } } } }7.4.6.1 General Slice Header Semanticssix_minus_max_num_merge_cand specifies the maximum number of mergingmotion vector prediction (MVP) candidates supported in the slicesubtracted from 6. The maximum number of merging MVP candidates,MaxNumMergeCand is derived as follows:MaxNumMergeCand=6−six_minus_max_num_merge_cand  (7-57)

The value of MaxNumMergeCand shall be in the range of 1 to 6, inclusive.

five_minus_max_num_subblock_merge_cand specifies the maximum number ofsubblock-based merging motion vector prediction (MVP) candidatessupported in the slice subtracted from 5. Whenfive_minus_max_num_subblock_merge_cand is not present, it is inferred tobe equal to 5−sps_sbtmvp_enabled_flag. The maximum number ofsubblock-based merging MVP candidates, MaxNumSubblockMergeCand isderived as follows:MaxNumSubblockMergeCand=5−five_minus_max_num_subblock_merge_cand  (7-58)

The value of MaxNumSubblockMergeCand shall be in the range of 0 to 5,inclusive.

7.4.8.5 Coding Unit Semantics

pred_mode_flag equal to 0 specifies that the current coding unit iscoded in inter prediction mode. pred_mode_flag equal to 1 specifies thatthe current coding unit is coded in intra prediction mode.

When pred_mode_flag is not present, it is inferred as follows:

-   -   If cbWidth is equal to 4 and cbHeight is equal to 4,        pred_mode_flag is inferred to be equal to 1.    -   Otherwise, pred_mode_flag is inferred to be equal to 1 when        decoding an I slice, and equal to 0 when decoding a P or B        slice, respectively.

The variable CuPredMode[x][y] is derived as follows for x=x0 . . .x0+cbWidth−1 and y=y0 . . . y0+cbHeight−1:

-   -   If pred_mode_flag is equal to 0, CuPredMode[x][y] is set equal        to MODE_INTER.    -   Otherwise (pred_mode_flag is equal to 1), CuPredMode[x][y] is        set equal to MODE_INTRA.        pred_mode_ibc_flag equal to 1 specifies that the current coding        unit is coded in IBC prediction mode. pred_mode_ibc_flag equal        to 0 specifies that the current coding unit is not coded in IBC        prediction mode.

When pred_mode_ibc_flag is not present, it is inferred as follows:

-   -   If cu_skip_flag[x0][y0] is equal to 1, and cbWidth is equal to        4, and cbHeight is equal to 4, pred_mode_ibc_flag is inferred to        be equal 1.    -   Otherwise, if both cbWidth and cbHeight are equal to 128,        pred_mode_ibc_flag is inferred to be equal to 0.    -   Otherwise, pred_mode_ibc_flag is inferred to be equal to the        value of sps_ibc_enabled_flag when decoding an I slice, and 0        when decoding a P or B slice, respectively.

When pred_mode_ibc_flag is equal to 1, the variable CuPredMode[x][y] isset to be equal to MODE_IBC for x=x0 . . . x0+cbWidth−1 and y=y0 . . .y0+cbHeight−1.

general_merge_flag[x0][y0] specifies whether the inter predictionparameters for the current coding unit are inferred from a neighbouringinter-predicted partition. The array indices x0, y0 specify the location(x0, y0) of the top-left luma sample of the considered coding blockrelative to the top-left luma sample of the picture.

When general_merge_flag[x0][y0] is not present, it is inferred asfollows:

-   -   If cu_skip_flag[x0][y0] is equal to 1,        general_merge_flag[x0][y0] is inferred to be equal to 1.    -   Otherwise, general_merge_flag[x0][y0] is inferred to be equal to        0.        mvp_l0_flag[x0][y0] specifies the motion vector predictor index        of list 0 where x0, y0 specify the location (x0, y0) of the        top-left luma sample of the considered coding block relative to        the top-left luma sample of the picture.

When mvp_l0_flag[x0][y0] is not present, it is inferred to be equal to0.

mvp_l1_flag[x0][y0] has the same semantics as mvp_l0_flag, with l0 andlist 0 replaced by l1 and list 1, respectively.

inter_pred_idc[x0][y0] specifies whether list0, list1, or bi-predictionis used for the current coding unit according to Table 7-10. The arrayindices x0, y0 specify the location (x, y0) of the top-left luma sampleof the considered coding block relative to the top-left luma sample ofthe picture.

TABLE 7-10 Name association to inter prediction mode Name ofinter_pred_idc ( cbWidth + ( cbWidth + ( cbWidth + inter_pred_idccbHeight ) > 12 cbHeight ) = = 12 cbHeight ) = = 8 0 PRED_L0 PRED_L0n.a. 1 PRED_L1 PRED_L1 n.a. 2 PRED_BI n.a. n.a.

When interpred_idc[x0][y0] is not present, it is inferred to be equal toPRED_L0.

7.4.8.7 Merge Data Semantics

regular_merge_flag[x0][y0] equal to 1 specifies that regular merge modeis used to generate the inter prediction parameters of the currentcoding unit. The array indices x0, y0 specify the location (x, y0) ofthe top-left luma sample of the considered coding block relative to thetop-left luma sample of the picture.

When regular_merge_flag[x0][y0] is not present, it is inferred asfollows:

-   -   If all the following conditions are true,        regular_merge_flag[x0][y0] is inferred to be equal to 1:        -   sps_mmvd_enabled_flag is equal to 0.        -   general_merge_flag[x0][y0] is equal to 1.        -   cbWidth*cbHeight is equal to 32.    -   Otherwise, regular_merge_flag[x0][y0] is inferred to be equal to        0.        mmvd_merge_flag[x0][y0] equal to 1 specifies that merge mode        with motion vector difference is used to generate the inter        prediction parameters of the current coding unit. The array        indices x0, y0 specify the location (x0, y0) of the top-left        luma sample of the considered coding block relative to the        top-left luma sample of the picture.

When mmvd_merge_flag[x0][y0] is not present, it is inferred as follows:

-   -   If all the following conditions are true,        mmvd_merge_flag[x0][y0] is inferred to be equal to 1:        -   sps_mmvd_enabled_flag is equal to 1.        -   general_merge_flag[x0][y0] is equal to 1.        -   cbWidth*cbHeight is equal to 32.        -   regular_merge_flag[x0][y0] is equal to 0.    -   Otherwise, mmvd_merge_flag[x0][y0] is inferred to be equal to 0.        mmvd_cand_flag[x0][y0] specifies whether the first (0) or the        second (1) candidate in the merging candidate list is used with        the motion vector difference derived from        mmvd_distance_idx[x0][y0] and mmvd_direction_idx[x0][y0]. The        array indices x0, y0 specify the location (x0, y0) of the        top-left luma sample of the considered coding block relative to        the top-left luma sample of the picture.

When mmvd_cand_flag[x0][y0] is not present, it is inferred to be equalto 0.

mmvd_distance_idx[x0][y0] specifies the index used to deriveMmvdDistance[x0][y0] as specified in Table 7-12. The array indices x0,y0 specify the location (x0, y0) of the top-left luma sample of theconsidered coding block relative to the top-left luma sample of thepicture.

TABLE 7-12 Specification of MmvdDistance[ x0 ][ y0 ] based onmmvd_distance_idx[ x0 ][ y0 ]. mmvd_distance_idx MmvdDistance[ x0 ][ y0] [ x0 ][ y0 ] slice_fpel_mmvd_enabled_flag = = 0slice_fpel_mmvd_enabled_flag = = 1 0 1 4 1 2 8 2 4 16 3 8 32 4 16 64 532 128 6 64 256 7 128 512mmvd_direction_idx[x0][y0] specifies index used to deriveMmvdSign[x0][y0] as specified in Table 7-13. The array indices x0, y0specify the location (x0, y0) of the top-left luma sample of theconsidered coding block relative to the top-left luma sample of thepicture.

TABLE 7-13 Specification of MmvdSign[ x0 ][ y0 ] based onmmvd_direction_idx[ x0 ][ y0 ] mmvd_direction_idx[ x0 ][ y0 ] MmvdSign[x0 ][ y0 ][0] MmvdSign[ x0 ][ y0 ][1] 0 +1 0 1 −1 0 2 0 +1 3 0 −1

Both components of the merge plus MVD offset MmvdOffset[x0][y0] arederived as follows:MmvdOffset[x0][y0][0]=(MmvdDistance[x0][y0]<<2)*MmvdSign[x0][y0][0]  (7-124)MmvdOffset[x0][y0][1]=(MmvdDistance[x0][y0]<<2)*MmvdSign[x0][y0][1]  (7-125)merge_subblock_flag[x0][y0] specifies whether the subblock-based interprediction parameters for the current coding unit are inferred fromneighbouring blocks. The array indices x0, y0 specify the location (x,y0) of the top-left luma sample of the considered coding block relativeto the top-left luma sample of the picture. Whenmerge_subblock_flag[x0][y0] is not present, it is inferred to be equalto 0.merge_subblock_idx[x0][y0] specifies the merging candidate index of thesubblock-based merging candidate list where x0, y0 specify the location(x, y0) of the top-left luma sample of the considered coding blockrelative to the top-left luma sample of the picture.

When merge_subblock_idx[x0][y0] is not present, it is inferred to beequal to 0.

ciip_flag[x0][y0] specifies whether the combined inter-picture merge andintra-picture prediction is applied for the current coding unit. Thearray indices x0, y0 specify the location (x, y0) of the top-left lumasample of the considered coding block relative to the top-left lumasample of the picture.

When ciip_flag[x0][y0] is not present, it is inferred to be equal to 0.

When ciip_flag[x0][y0] is equal to 1, the variable IntraPredModeY[x][y]with x=xCb . . . xCb+cbWidth−1 and y=yCb . . . yCb+cbHeight−1 is set tobe equal to INTRA_PLANAR.

The variable MergeTriangleFlag[x0][y0], which specifies whethertriangular shape based motion compensation is used to generate theprediction samples of the current coding unit, when decoding a B slice.is derived as follows:

-   -   If all the following conditions are true,        MergeTriangleFlag[x0][y0] is set equal to 1:        -   sps_triangle_enabled_flag is equal to 1.        -   slice_type is equal to B.        -   general_merge_flag[x0][y0] is equal to 1.        -   MaxNumTriangleMergeCand is greater than or equal to 2.        -   cbWidth*cbHeight is greater than or equal to 64.        -   regular_merge_flag[x0][y0] is equal to 0.        -   mmvd_merge_flag[x0][y0] is equal to 0.        -   merge_subblock_flag[x0][y0] is equal to 0.        -   ciip_flag[x0][y0] is equal to 0.    -   Otherwise, MergeTriangleFlag[x0][y0] is set equal to 0.        merge_triangle_split_dir[x0][y0] specifies the splitting        direction of merge triangle mode. The array indices x0, y0        specify the location (x0, y0) of the top-left luma sample of the        considered coding block relative to the top-left luma sample of        the picture.

When merge_triangle_split_dir[x0][y0] is not present, it is inferred tobe equal to 0.

merge_triangle_idx0[x0][y0] specifies the first merging candidate indexof the triangular shape based motion compensation candidate list wherex0, y0 specify the location (x0, y0) of the top-left luma sample of theconsidered coding block relative to the top-left luma sample of thepicture.

When merge_triangle_idx0[x0][y0] is not present, it is inferred to beequal to 0.

merge_triangle_idx1[x0][y0] specifies the second merging candidate indexof the triangular shape based motion compensation candidate list wherex, y0 specify the location (x, y0) of the top-left luma sample of theconsidered coding block relative to the top-left luma sample of thepicture.

When merge_triangle_idx1[x0][y0] is not present, it is inferred to beequal to 0.

merge_idx[x0][y0] specifies the merging candidate index of the mergingcandidate list where x, y0 specify the location (x, y0) of the top-leftluma sample of the considered coding block relative to the top-left lumasample of the picture.

When merge_idx[x0][y0] is not present, it is inferred as follows:

-   -   If mmvd_merge_flag[x0][y0] is equal to 1, merge_idx[x0][y0] is        inferred to be equal to mmvd_cand_flag[x0][y0].    -   Otherwise (mmvd_merge_flag[x0][y0] is equal to 0),        merge_idx[x0][y0] is inferred to be equal to 0.        2.2.4.4.1 Decoding Process

The decoding process as provided in the JVET-N0340 is defined asfollows:

8.5.2.2 Derivation Process for Luma Motion Vectors for Merge Mode

This process is only invoked when general_merge_flag[xCb][yCb] is equalto 1, where (xCb, yCb) specify the top-left sample of the current lumacoding block relative to the top-left luma sample of the currentpicture.

Inputs to this process are:

-   -   a luma location (xCb, yCb) of the top-left sample of the current        luma coding block relative to the top-left luma sample of the        current picture,    -   a variable cbWidth specifying the width of the current coding        block in luma samples,    -   a variable cbHeight specifying the height of the current coding        block in luma samples.

Outputs of this process are:

-   -   the luma motion vectors in 1/16 fractional-sample accuracy        mvL0[0][0] and mvL1[0][0],    -   the reference indices refIdxL0 and refIdxL1,    -   the prediction list utilization flags predFlagL0[0][0] and        predFlagL1[0][0],    -   the bi-prediction weight index bcwIdx.    -   the merging candidate list mergeCandList.

The bi-prediction weight index bcwIdx is set equal to 0.

The motion vectors mvL0[0][0] and mvL1[0][0], the reference indicesrefIdxL0 and refIdxL1 and the prediction utilization flagspredFlagL0[0][0] and predFlagL1[0][0] are derived by the followingordered steps:

-   -   1. The derivation process for spatial merging candidates from        neighbouring coding units as specified in clause 8.5.2.3 is        invoked with the luma coding block location (xCb, yCb), the luma        coding block width cbWidth, and the lumacoding block height        cbHeight as inputs, and the output being the availability flags        availableFlagA₀, availableFlagA₁, availableFlagB₀,        availableFlagB₁ and availableFlagB₂, the reference indices        refIdxLXA₀, refIdxLXA₁, refIdxLXB₀, refIdxLXB₁ and refIdxLXB₂,        the prediction list utilization flags predFlagLXA₀,        predFlagLXA₁, predFlagLXB₀, predFlagLXB₁ and predFlagLXB₂, and        the motion vectors mvLXA₀, mvLXA₁, mvLXB₀, mvLXB₁ and mvLXB₂,        with X being 0 or 1, and the bi-prediction weight indices        bcwIdxA₀, bcwIdxA₁, bcwIdxB₀, bcwIdxB₁, bcwIdxB₂.    -   2. The reference indices, refIdxLXCol, with X being 0 or 1, and        the bi-prediction weight index bcwIdxCol for the temporal        merging candidate Col are set equal to 0.    -   3. The derivation process for temporal luma motion vector        prediction as specified in in clause 8.5.2.11 is invoked with        the luma location (xCb, yCb), the luma coding block width        cbWidth, the luma coding block height cbHeight and the variable        refIdxL0Col as inputs, and the output being the availability        flag availableFlagL0Col and the temporal motion vector mvL0Col.        The variables availableFlagCol, predFlagL0Col and predFlagL1Col        are derived as follows:        availableFlagCol=availableFlagL0Col  (8-263)        predFlagL0Col=availableFlagL0Col  (8-264)        predFlagL1Col=0  (8-265)    -   4. When slice_type is equal to B, the derivation process for        temporal luma motion vector prediction as specified in clause        8.5.2.11 is invoked with the luma location (xCb, yCb), the luma        coding block width cbWidth, the luma coding block height        cbHeight and the variable refIdxL1Col as inputs, and the output        being the availability flag availableFlagL1Col and the temporal        motion vector mvL1Col. The variables availableFlagCol and        predFlagL1Col are derived as follows:        availableFlagCol=availableFlagL0Col availableFlagL1Col  (8-266)        predFlagL1Col=availableFlagL1Col  (8-267)    -   5. The merging candidate list, mergeCandList, is constructed as        follows:        i=0        if(availableFlagA ₁)        mergeCandList[i++]=A ₁        if(availableFlagB ₁)        mergeCandList[i++]=B ₁        if(availableFlagB ₀)        mergeCandList[i++]=B ₀        if(availableFlagA ₀)        mergeCandList[i++]=A ₀        if(availableFlagB ₂)        mergeCandList[i++]=B ₂        if(availableFlagCol)        mergeCandList[i++]=Col  (8-268)    -   6. The variable numCurrMergeCand and numOrigMergeCand are set        equal to the number of merging candidates in the mergeCandList.    -   7. When numCurrMergeCand is less than (MaxNumMergeCand−1) and        NumHmvpCand is greater than 0, the following applies:        -   The derivation process of history-based merging candidates            as specified in 8.5.2.6 is invoked with mergeCandList and            numCurrMergeCand as inputs, and modified mergeCandList and            numCurrMergeCand as outputs.        -   numOrigMergeCand is set equal to numCurrMergeCand.    -   8. When numCurrMergeCand is less than MaxNumMergeCand and        greater than 1, the following applies:        -   The derivation process for pairwise average merging            candidate specified in clause 8.5.2.4 is invoked with            mergeCandList, the reference indices refIdxL0N and            refIdxL1N, the prediction list utilization flags predFlagL0N            and predFlagL1N, the motion vectors mvL0N and mvL1N of every            candidate N in mergeCandList, and numCurrMergeCand as            inputs, and the output is assigned to mergeCandList,            numCurrMergeCand, the reference indices refIdxL0avgCand and            refIdxL1avgCand, the prediction list utilization flags            predFlagL0avgCand and predFlagL1avgCand and the motion            vectors mvL0avgCand and mvL1avgCand of candidate avgCand            being added into mergeCandList. The bi-prediction weight            index bcwIdx of candidate avgCand being added into            mergeCandList is set equal to 0.        -   numOrigMergeCand is set equal to numCurrMergeCand.    -   9. The derivation process for zero motion vector merging        candidates specified in clause 8.5.2.5 is invoked with the        mergeCandList, the reference indices refIdxL0N and refIdxL1N,        the prediction list utilization flags predFlagL0N and        predFlagL1N, the motion vectors mvL0N and mvL1N of every        candidate N in mergeCandList and numCurrMergeCand as inputs, and        the output is assigned to mergeCandList, numCurrMergeCand, the        reference indices refIdxL0zeroCand_(m) and refIdxL1zeroCand_(m),        the prediction list utilization flags predFlagL0zeroCand_(m) and        predFlagL1zeroCand_(m) and the motion vectors mvL0zeroCand_(m)        and mvL1zeroCand_(m) of every new candidate zeroCand_(m) being        added into mergeCandList. The bi-prediction weight index bcwIdx        of every new candidate zeroCand_(m) being added into        mergeCandList is set equal to 0. The number of candidates being        added, numZeroMergeCand, is set equal to        (numCurrMergeCand−numOrigMergeCand). When numZeroMergeCand is        greater than 0, m ranges from 0 to numZeroMergeCand−1,        inclusive.    -   10. The following assignments are made with N being the        candidate at position merge_idx[xCb][yCb] in the merging        candidate list mergeCandList        (N=mergeCandList[merge_idx[xCb][yCb]]) and X being replaced by 0        or 1:        refIdxLX=refIdxLXN  (8-269)        predFlagLX[0][0]=predFlagLXN  (8-270)        mvLX[0][0][0]=mvLXN[0]  (8-271)        mvLX[0][0][1]=mvLXN[1]  (8-272)        bcwIdx=bcwIdxN  (8-273)    -   11. When mmvd_merge_flag[xCb][yCb] is equal to 1, the following        applies:        -   The derivation process for merge motion vector difference as            specified in 8.5.2.7 is invoked with the luma location (xCb,            yCb), the reference indices refIdxL0, refIdxL1 and the            prediction list utilization flags predFlagL0[0][0] and            predFlagL1[0][0] as inputs, and the motion vector            differences mMvdL0 and mMvdL1 as outputs.        -   The motion vector difference mMvdLX is added to the merge            motion vectors mvLX for X being 0 and 1 as follows:            mvLX[0][0][0]+=mMvdLX[0]  (8-274)            mvLX[0][0][1]+=mMvdLX[1]  (8-275)            mvLX[0][0][0]=Clip3(−2¹⁷,2¹⁷−1,mvLX[0][0][0])  (8-276)            mvLX[0][0][1]=Clip3(−2¹⁷,2¹⁷−1,mvLX[0][0][1])  (8-277)            8.5.2.3 Derivation Process for Spatial Merging Candidates

Inputs to this process are:

-   -   a luma location (xCb, yCb) of the top-left sample of the current        luma coding block relative to the top-left luma sample of the        current picture,    -   a variable cbWidth specifying the width of the current coding        block in luma samples,    -   a variable cbHeight specifying the height of the current coding        block in luma samples.

Outputs of this process are as follows, with X being 0 or 1:

-   -   the availability flags availableFlagA₀, availableFlagA₁,        availableFlagB₀, availableFlagB₁ and availableFlagB₂ of the        neighbouring coding units,    -   the reference indices refIdxLXA₀, refIdxLXA₁, refIdxLXB₀,        refIdxLXB₁ and refIdxLXB₂ of the neighbouring coding units,    -   the prediction list utilization flags predFlagLXA₀,        predFlagLXA₁, predFlagLXB₀, predFlagLXB₁ and predFlagLXB₂ of the        neighbouring coding units,    -   the motion vectors in 1/16 fractional-sample accuracy mvLXA₀,        mvLXA₁, mvLXB₀, mvLXB₁ and mvLXB₂ of the neighbouring coding        units,    -   the bi-prediction weight indices gbiIdxA₀, gbiIdxA₁, gbiIdxB₀,        gbiIdxB₁, and gbiIdxB₂.

For the derivation of availableFlagA₁, refIdxLXA₁, predFlagLXA₁ andmvLXA₁ the following applies:

-   -   The luma location (xNbA₁, yNbA₁) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbHeight−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbA₁, yNbA₁) as inputs, and the output is assigned to        the block availability flag availableA₁.    -   The variables availableFlagA₁, refIdxLXA₁, predFlagLXA₁ and        mvLXA₁ are derived as follows:        -   If availableA₁ is equal to FALSE, availableFlagA₁ is set            equal to 0, both components of mvLXA₁ are set equal to 0,            refIdxLXA₁ is set equal to −1 and predFlagLXA₁ is set equal            to 0, with X being 0 or 1, and gbiIdxA₁ is set equal to 0.        -   Otherwise, availableFlagA₁ is set equal to 1 and the            following assignments are made:            mvLXA ₁=MvLX[xNbA ₁][yNbA ₁]  (8-294)            refIdxLXA ₁=RefIdxLX[xNbA ₁][yNbA ₁]  (8-295)            predFlagLXA ₁=PredFlagLX[xNbA ₁][yNbA ₁]  (8-296)            gbiIdxA ₁=GbiIdx[xNbA ₁][yNbA ₁]  (8-297)

For the derivation of availableFlagB₁, refIdxLXB₁, predFlagLXB₁ andmvLXB₁ the following applies:

-   -   The luma location (xNbB₁, yNbB1) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth−1, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₁, yNbB1) as inputs, and the output is assigned to        the block availability flag availableB₁.    -   The variables availableFlagB₁, refIdxLXB₁, predFlagLXB₁ and        mvLXB₁ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₁ is set equal to 0, both components of mvLXB₁            are set equal to 0, refIdxLXB₁ is set equal to −1 and            predFlagLXB₁ is set equal to 0, with X being 0 or 1, and            gbiIdxB₁ is set equal to 0:            -   availableB₁ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbB₁, yNbB1) have the same motion                vectors and the same reference indices.        -   Otherwise, availableFlagB₁ is set equal to 1 and the            following assignments are made:            mvLXB ₁=MvLX[xNbB ₁][yNbB1]  (8-298)            refIdxLXB ₁=RefIdxLX[xNbB ₁][yNbB1]  (8-299)            predFlagLXB ₁=PredFlagLX[xNbB ₁][yNbB1]  (8-300)            gbiIdxB ₁=GbiIdx[xNbB ₁][yNbB1]  (8-301)

For the derivation of availableFlagB₀, refIdxLXB₀, predFlagLXB₀ andmvLXB₀ the following applies:

-   -   The luma location (xNbB₀, yNbB₀) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₀, yNbB₀) as inputs, and the output is assigned to        the block availability flag availableB₀.    -   The variables availableFlagB₀, refIdxLXB₀, predFlagLXB₀ and        mvLXB₀ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₀ is set equal to 0, both components of mvLXB₀            are set equal to 0, refIdxLXB₀ is set equal to −1 and            predFlagLXB₀ is set equal to 0, with X being 0 or 1, and            gbiIdxB₀ is set equal to 0:            -   availableB₀ is equal to FALSE.            -   availableB₁ is equal to TRUE and the luma locations                (xNbB₁, yNbB1) and (xNbB₀, yNbB₀) have the same motion                vectors and the same reference indices.            -   availableA₁ is equal to TRUE, the luma locations (xNbA₁,                yNbA₁) and (xNbB₀, yNbB₀) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.        -   Otherwise, availableFlagB₀ is set equal to 1 and the            following assignments are made:            mvLXB ₀=MvLX[xNbB ₀][yNbB ₀]  (8-302)            refIdxLXB ₀=RefIdxLX[xNbB ₀][yNbB ₀]  (8-303)            predFlagLXB ₀=PredFlagLX[xNbB ₀][yNbB ₀]  (8-304)            gbiIdxB ₀=GbiIdx[xNbB ₀][yNbB ₀]  (8-305)

For the derivation of availableFlagA₀, refIdxLXA₀, predFlagLXA₀ andmvLXA₀ the following applies:

-   -   The luma location (xNbA₀, yNbA₀) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbWidth).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbA₀, yNbA₀) as inputs, and the output is assigned to        the block availability flag availableA₀.    -   The variables availableFlagA₀, refIdxLXA₀, predFlagLXA₀ and        mvLXA₀ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagA₀ is set equal to 0, both components of mvLXA₀            are set equal to 0, refIdxLXA₀ is set equal to −1 and            predFlagLXA₀ is set equal to 0, with X being 0 or 1, and            gbiIdxA₀ is set equal to 0:            -   availableA₀ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbA₀, yNbA₀) have the same motion                vectors and the same reference indices.            -   availableB₁ is equal to TRUE, the luma locations (xNbB₁,                yNbB1) and (xNbA₀, yNbA₀) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.            -   availableB₀ is equal to TRUE, the luma locations (xNbB₀,                yNbB₀) and (xNbA₀, yNbA₀) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.        -   Otherwise, availableFlagA₀ is set equal to 1 and the            following assignments are made:            mvLXA ₀=MvLX[xNbA ₀][yNbA ₀]  (8-306)            refIdxLXA ₀=RefIdxLX[xNbA ₀][yNbA ₀]  (8-307)            predFlagLXA ₀=PredFlagLX[xNbA ₀][yNbA ₀]  (8-308)            gbiIdxA ₀=GbiIdx[xNbA ₀][yNbA ₀]  (8-309)

For the derivation of availableFlagB₂, refIdxLXB₂, predFlagLXB₂ andmvLXB₂ the following applies:

-   -   The luma location (xNbB₂, yNbB₂) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₂, yNbB₂) as inputs, and the output is assigned to        the block availability flag availableB₂.    -   The variables availableFlagB₂, refIdxLXB₂, predFlagLXB₂ and        mvLXB₂ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₂ is set equal to 0, both components of mvLXB₂            are set equal to 0, refIdxLXB₂ is set equal to −1 and            predFlagLXB₂ is set equal to 0, with X being 0 or 1, and            gbiIdxB₂ is set equal to 0:            -   availableB₂ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₁ is equal to TRUE and the luma locations                (xNbB₁, yNbB1) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₀ is equal to TRUE, the luma locations (xNbB₀,                yNbB₀) and (xNbB₂, yNbB₂) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.            -   availableA₀ is equal to TRUE, the luma locations (xNbA₀,                yNbA₀) and (xNbB₂, yNbB₂) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.            -   availableFlagA₀+availableFlagA₁+availableFlagB₀+availableFlagB₁                is equal to 4 and merge_triangle_flag[xCb][yCb] is equal                to 0.        -   Otherwise, availableFlagB₂ is set equal to 1 and the            following assignments are made:            mvLXB ₂=MvLX[xNbB ₂][yNbB ₂]  (8-310)            refIdxLXB ₂=RefIdxLX[xNbB ₂][yNbB ₂]  (8-311)            predFlagLXB ₂=PredFlagLX[xNbB ₂][yNbB ₂]  (8-312)            gbiIdxB ₂=GbiIdx[xNbB ₂][yNbB ₂]  (8-313)            2.2.5 MMVD

In JVET-L0054, ultimate motion vector expression (UMVE, also known asMMVD) is presented. UMVE is used for either skip or merge modes with aproposed motion vector expression method.

UMVE re-uses merge candidate as same as those included in the regularmerge candidate list in VVC. Among the merge candidates, abase candidatecan be selected, and is further expanded by the proposed motion vectorexpression method.

UMVE provides anew motion vector difference (MVD) representation method,in which a starting point, a motion magnitude and a motion direction areused to represent a MVD.

This proposed technique uses a merge candidate list as it is. But onlycandidates which are default merge type (MRG_TYPE_DEFAULT_N) areconsidered for UMVE's expansion.

Base candidate index defines the starting point. Base candidate indexindicates the best candidate among candidates in the list as follows.

TABLE 4 Base candidate IDX Base candidate IDX 0 1 2 3 N^(th) MVP 1^(st)MVP 2^(nd) MVP 3^(rd) MVP 4^(th) MVP

If the number of base candidate is equal to 1, Base candidate IDX is notsignaled.

Distance index is motion magnitude information. Distance index indicatesthe pre-defined distance from the starting point information.Pre-defined distance is as follows:

TABLE 5 Distance IDX Distance IDX 0 1 2 3 4 5 6 7 Pixel ¼- ½- 1- 2- 4-8- 16- 32- distance pel pel pel pel pel pel pel pel

Direction index represents the direction of the MVD relative to thestarting point. The direction index can represent of the four directionsas shown below.

TABLE 6 Direction IDX Direction IDX 00 01 10 11 x-axis + − N/A N/Ay-axis N/A N/A + −

UMVE flag is signaled right after sending a skip flag or merge flag. Ifskip or merge flag is true, UMVE flag is parsed. If UMVE flag is equalto 1, UMVE syntaxes are parsed. But, if not 1, AFFINE flag is parsed. IfAFFINE flag is equal to 1, that is AFFINE mode, But, if not 1,skip/merge index is parsed for VTM's skip/merge mode.

Additional line buffer due to UMVE candidates is not needed. Because askip/merge candidate of software is directly used as a base candidate.Using input UMVE index, the supplement of MV is decided right beforemotion compensation. There is no need to hold long line buffer for this.

In current common test condition, either the first or the second mergecandidate in the merge candidate list could be selected as the basecandidate.

UMVE is also known as Merge with MV Differences (MMVD).

2.2.6 Combined Intra-Inter Prediction (CIIP)

In JVET-L0100, multi-hypothesis prediction is proposed, wherein combinedintra and inter prediction is one way to generate multiple hypotheses.

When the multi-hypothesis prediction is applied to improve intra mode,multi-hypothesis prediction combines one intra prediction and one mergeindexed prediction. In a merge CU, one flag is signaled for merge modeto select an intra mode from an intra candidate list when the flag istrue. For luma component, the intra candidate list is derived from onlyone intra prediction mode, i.e., planar mode. The weights applied to theprediction block from intra and inter prediction are determined by thecoded mode (intra or non-intra) of two neighboring blocks (A1 and B1).

2.2.7 MERGE for Sub-Block-Based Technologies

It is suggested that all the sub-block related motion candidates are putin a separate merge list in addition to the regular merge list fornon-sub block merge candidates.

The sub-block related motion candidates are put in a separate merge listis named as ‘sub-block merge candidate list’.

In one example, the sub-block merge candidate list includes ATMVPcandidate and affine merge candidates.

The sub-block merge candidate list is filled with candidates in thefollowing order:

-   -   a. ATMVP candidate (may be available or unavailable);    -   b. Affine merge lists (including Inherited Affine candidates;        and Constructed Affine candidates)    -   c. Padding as zero MV 4-parameter affine model        2.2.7.1.1 ATMVP (aka Sub-block Temporal Motion Vector Predictor,        SbTMVP)

Basic idea of ATMVP is to derive multiple sets of temporal motion vectorpredictors for one block. Each sub-block is assigned with one set ofmotion information. When an ATMVP merge candidate is generated, themotion compensation is done in 8×8 level instead of the whole blocklevel.

In current design, ATMVP predicts the motion vectors of the sub-CUswithin a CU in two steps which are described in the following twosub-sections 2.2.7.1.1.1 and 2.2.7.1.1.2, respectively.

2.2.7.1.1.1 Derivation of Initialized Motion Vector

Denote the initialized motion vector by tempMv. When block A1 isavailable and non-intra coded (i.e., coded with inter or IBC mode), thefollowing is applied to derive the initialized motion vector.

-   -   If all of the following conditions are true, tempMv is set equal        to the motion vector of block A1 from list 1, denoted by mvL1A₁:        -   Reference picture index of list 1 is available (not equal to            −1), and it has the same POC value as the collocated picture            (i.e., DiffPicOrderCnt(ColPic, RefPicList[1][refIdxL1A₁]) is            equal to 0),        -   All reference pictures are with no larger POC compared to            the current picture (i.e., DiffPicOrderCnt(aPic, currPic) is            less than or equal to 0 for every picture aPic in every            reference picture list of the current slice),        -   Current slice is equal to B slice,        -   collocated_from_l0_flag is equal to 0.    -   Otherwise if all of the following conditions are true, tempMv is        set equal to the motion vector of block A1 from list 0, denoted        by mvL0A1:        -   Reference picture index of list 0 is available (not equal to            −1),        -   it has the same POC value as the collocated picture (i.e.,            DiffPicOrderCnt(ColPic, RefPicList[0][refIdxL0A₁]) is equal            to 0).    -   Otherwise, zero motion vector is used as the initialized MV.

A corresponding block (with center position of current block plus therounded MV, clipped to be in certain ranges in necessary) is identifiedin the collocated picture signaled at the slice header with theinitialized motion vector.

If the block is inter-coded, then go to the 2^(nd) step. Otherwise, theATMVP candidate is set to be NOT available.

2.2.7.1.1.2 Sub-CU Motion Derivation

The second step is to split the current CU into sub-CUs and obtain themotion information of each sub-CU from the block corresponding to eachsub-CU in the collocated picture.

If the corresponding block for a sub-CU is coded with inter mode, themotion information is utilized to derive the final motion information ofcurrent sub-CU by invoking the derivation process for collocated MVswhich is not different with the process for conventional TMVP process.Basically, if the corresponding block is predicted from the target listX for uni-prediction or bi-prediction, the motion vector is utilized;otherwise, if it is predicted from list Y (Y=1−X) for uni orbi-prediction and NoBackwardPredFlag is equal to 1, MV for list Y isutilized. Otherwise, no motion candidate could be found.

If the block in the collocated picture identified by the initialized MVand location of current sub-CU is intra or IBC coded, or no motioncandidate could be found as described aforementioned, the followingfurther apply:

Denote the motion vector used to fetch the motion field in thecollocated picture R_(col) as MV_(col). To minimize the impact due to MVscaling, the MV in the spatial candidate list used to derive MV_(col) isselected in the following way: if the reference picture of a candidateMV is the collocated picture, this MV is selected and used as MV_(col)without any scaling. Otherwise, the MV having a reference pictureclosest to the collocated picture is selected to derive MV_(col) withscaling.

The related decoding process for collocated motion vectors derivationprocess in JVET-N1001 is described as follows, with the parts related toATMVP highlighted in bolded, underlined, italicized font:

8.5.2.12 Derivation Process for Collocated Motion Vectors

Inputs to this process are:

-   -   a variable currCb specifying the current coding block,    -   a variable colCb specifying the collocated coding block inside        the collocated picture specified by ColPic,    -   a luma location (xColCb, yColCb) specifying the top-left sample        of the collocated luma coding block specified by colCb relative        to the top-left luma sample of the collocated picture specified        by ColPic,    -   a reference index refIdxLX, with X being 0 or 1,    -   a flag indicating a subblock temporal merging candidate sbFlag.

Outputs of this process are:

-   -   the motion vector prediction mvLXCol in 1/16 fractional-sample        accuracy,    -   the availability flag availableFlagLXCol.

The variable currPic specifies the current picture.

The arrays predFlagL0Col[x][y], mvL0Col[x][y] and refIdxL0Col[x][y] areset equal to PredFlagL0[x][y], MvDmvrL0[x][y] and RefIdxL0[x][y],respectively, of the collocated picture specified by ColPic, and thearrays predFlagL1Col[x][y], mvL1Col[x][y] and refIdxL1Col[x][y] are setequal to PredFlagL1[x][y], MvDmvrL1[x][y] and RefIdxL1[x][y],respectively, of the collocated picture specified by ColPic.

The variables mvLXCol and availableFlagLXCol are derived as follows:

-   -   If colCb is coded in an intra or IBC prediction mode, both        components of mvLXCol are set equal to 0 and availableFlagLXCol        is set equal to 0.    -   Otherwise, the motion vector mvCol, the reference index        refIdxCol and the reference list identifier listCol are derived        as follows:        -   If sbFlag is equal to 0, availableFlagLXCol is set to 1 and            the following applies:            -   If predFlagL0Col[xColCb][yColCb] is equal to 0, mvCol,                refIdxCol and listCol are set equal to                mvL1Col[xColCb][yColCb], refIdxL1Col[xColCb][yColCb] and                L1, respectively.            -   Otherwise, if predFlagL0Col[xColCb][yColCb] is equal to                1 and predFlagL1 Col[xColCb][yColCb] is equal to 0,                mvCol, refIdxCol and listCol are set equal to                mvL0Col[xColCb][yColCb], refIdxL0Col[xColCb][yColCb] and                L0, respectively.            -   Otherwise (predFlagL0Col[xColCb][yColCb] is equal to 1                and predFlagL1Col[xColCb][yColCb] is equal to 1), the                following assignments are made:                -   If NoBackwardPredFlag is equal to 1, mvCol,                    refIdxCol and listCol are set equal to                    mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb]                    and LX, respectively.                -   Otherwise, mvCol, refIdxCol and listCol are set                    equal to mvLNCol[xColCb][yColCb],                    refIdxLNCol[xColCb][yColCb] and LN, respectively,                    with N being the value of collocated_from_l0_flag.        -   Otherwise (sbFlag is equal to 1), the following applies:            -   If PredFlagLXCol[xColCb][yColCb] is equal to 1, mvCol,                refIdxCol, and listCol are set equal to                mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb],                and LX respectively, availableFlagLXCol is set to 1.            -   Otherwise (PredFlagLXCol[xColCb][yColCb] is equal to 0),                the following applies:                -   If DiffPicOrderCnt(aPic, currPic) is less than or                    equal to 0 for every picture aPic in every reference                    picture list of the current slice and                    PredFlagLYCol[xColCb][yColCb] is equal to 1, mvCol,                    refIdxCol, and listCol are set to                    mvLYCol[xColCb][ColCb], refIdxLYCol[xColCb][yColCb]                    and LY, respectively, with Y being equal to !X where                    X being the value of X this process is invoked for.                    availableFlagLXCol is set to 1.                -   Both the components of mvLXCol are set to 0 and                    availableFlagLXCol is set equal to 0.        -   When availableFlagLXCol is equal to TRUE, mvLXCol and            availableFlagLXCol are derived as follows:            -   If LongTermRefPic(currPic, currCb, refIdxLX, LX) is not                equal to LongTermRefPic(ColPic, colCb, refIdxCol,                listCol), both components of mvLXCol are set equal to 0                and availableFlagLXCol is set equal to 0.            -   Otherwise, the variable availableFlagLXCol is set equal                to 1, refPicList[listCol][refIdxCol] is set to be the                picture with reference index refIdxCol in the reference                picture list listCol of the slice containing coding                block colCb in the collocated picture specified by                ColPic, and the following applies:                colPocDiff=DiffPicOrderCnt(ColPic,refPicList[listCol][refIdxCol])  (8-402)                currPocDiff=DiffPicOrderCnt(currPic,RefPicList[X][refIdxLX])  (8-403)                -   The temporal motion buffer compression process for                    collocated motion vectors as specified in clause                    8.5.2.15 is invoked with mvCol as input, and the                    modified mvCol as output.                -   If RefPicList[X][refIdxLX] is a long-term reference                    picture, or colPocDiff is equal to currPocDiff,                    mvLXCol is derived as follows:                    mvLXCol=mvCol  (8-404)                -   Otherwise, mvLXCol is derived as a scaled version of                    the motion vector mvCol as follows:                    tx=(16384+(Abs(td)>>1))/td  (8-405)                    distScaleFactor=Clip3(−4096,4095,(tb*tx+32)>>6)  (8-406)                    mvLXCol=Clip3(−131072,131071,(distScaleFactor*mvCol+128−(distScaleFactor*mvCol>=0))>>8))  (8-407)                -   where td and tb are derived as follows:                    td=Clip3(−128,127,colPocDiff)  (8-408)                    tb=Clip3(−128,127,currPocDiff)  (8-409)                    2.2.8 Regular Inter Mode (AMVP)                    2.2.8.1 AMVP Motion Candidate List

Similar to the AMVP design in HEVC, up to 2 AMVP candidates may bederived. However, the HMVP candidates may also be added after the TMVPcandidate. The HMVP candidates in the HMVP table are traversed in anascending order of index (i.e., from index equal to 0, the oldest one).Up to 4 HMVP candidates may be checked to find whether its referencepicture is the same as the target reference picture (i.e., same POCvalue).

2.2.8.2 AMVR

In HEVC, motion vector differences (MVDs) (between the motion vector andpredicted motion vector of a PU) are signalled in units of quarter lumasamples when use_integer_mv_flag is equal to 0 in the slice header. Inthe VVC, a locally adaptive motion vector resolution (AMVR) isintroduced. In the VVC, MVD can be coded in units of quarter lumasamples, integer luma samples or four luma samples (i.e., ¼-pel, 1-pel,4-pel). The MVD resolution is controlled at the coding unit (CU) level,and MVD resolution flags are conditionally signalled for each CU thathas at least one non-zero MVD components.

For a CU that has at least one non-zero MVD components, a first flag issignalled to indicate whether quarter luma sample MV precision is usedin the CU. When the first flag (equal to 1) indicates that quarter lumasample MV precision is not used, another flag is signalled to indicatewhether integer luma sample MV precision or four luma sample MVprecision is used.

When the first MVD resolution flag of a CU is zero, or not coded for aCU (meaning all MVDs in the CU are zero), the quarter luma sample MVresolution is used for the CU. When a CU uses integer-luma sample MVprecision or four-luma-sample MV precision, the MVPs in the AMVPcandidate list for the CU are rounded to the corresponding precision.

2.2.8.3 Symmetric motion vector difference in JVET-N1001-v2

In JVET-N1001-v2, symmetric motion vector difference (SMVD) is appliedfor motion information coding in bi-prediction.

Firstly, in slice level, variables RefIdxSymL0 and RefIdxSymL1 toindicate the reference picture index of list 0/1 used in SMVD mode,respectively, are derived with the following steps as specified inN1001-v2. When at least one of the two variables are equal to −1, SMVDmode shall be disabled.

2.2.9 Refinement of Motion Information

2.2.9.1 Decoder-Side Motion Vector Refinement (DMVR)

In bi-prediction operation, for the prediction of one block region, twoprediction blocks, formed using a motion vector (MV) of list0 and a MVof list1, respectively, are combined to form a single prediction signal.In the decoder-side motion vector refinement (DMVR) method, the twomotion vectors of the bi-prediction are further refined.

For DMVR in VVC, MVD mirroring between list 0 and list 1 is assumed asshown in FIG. 19 and bilateral matching is performed to refine the MVs,i.e., to find the best MVD among several MVD candidates. Denote the MVsfor two reference picture lists by MVL0(L0X, L0Y), and MVL1(L1X, L1Y).The MVD denoted by (MvdX, MvdY) for list 0 that could minimize the costfunction (e.g., SAD) is defined as the best MVD. For the SAD function,it is defined as the SAD between the reference block of list 0 derivedwith a motion vector (L0X+MvdX, L0Y+MvdY) in the list 0 referencepicture and the reference block of list 1 derived with a motion vector(L1X−MvdX, L1Y−MvdY) in the list 1 reference picture.

The motion vector refinement process may iterate twice. In eachiteration, at most 6 MVDs (with integer-pel precision) may be checked intwo steps, as shown in FIG. 20. In the first step, MVD (0, 0), (−1, 0),(1, 0), (0, −1), (0, 1) are checked. In the second step, one of the MVD(−1, −1), (−1, 1), (1, −1) or (1, 1) may be selected and furtherchecked. Suppose function Sad(x, y) returns SAD value of the MVD (x, y).The MVD, denoted by (MvdX, MvdY), checked in the second step is decidedas follows:MvdX=−1;MvdY=−1;If (Sad(1,0)<Sad(−1,0))MvdX=1;If (Sad(0,1)<Sad(0,−1))MvdY=1;

In the first iteration, the starting point is the signaled MV, and inthe second iteration, the starting point is the signaled MV plus theselected best MVD in the first iteration. DMVR applies only when onereference picture is a preceding picture and the other reference pictureis a following picture, and the two reference pictures are with samepicture order count distance from the current picture.

To further simplify the process of DMVR, JVET-M0147 proposed severalchanges to the design in JEM. More specifically, the adopted DMVR designto VTM-4.0 (to be released soon) has the following main features:

-   -   Early termination when (0,0) position SAD between list0 and        list1 is smaller than a threshold.    -   Early termination when SAD between list0 and list1 is zero for        some position.    -   Block sizes for DMVR: W*H>=64 && H>=8, wherein W and H are the        width and height of the block.    -   Split the CU into multiple of 16×16 sub-blocks for DMVR of CU        size>16*16. If only width or height of the CU is larger than 16,        it is only split in vertical or horizontal direction.    -   Reference block size (W+7)*(H+7) (for luma).    -   25 points SAD-based integer-pel search (i.e. (+−) 2 refinement        search range, single stage)    -   Bilinear-interpolation based DMVR.    -   “Parametric error surface equation” based sub-pel refinement.        This procedure is performed only when the minimum SAD cost is        not equal to zero and the best MVD is (0, 0) in the last MV        refinement iteration.    -   Luma/chroma MC w/reference block padding (if needed).    -   Refined MVs used for MC and TMVPs only.        2.2.9.1.1 Usage of DMVR

When the following conditions are all true, DMVR may be enabled:

-   -   DMVR enabling flag in the SPS (i.e., sps_dmvr_enabled_flag) is        equal to 1    -   TPM flag, inter-affine flag and subblock merge flag (either        ATMVP or affine merge), MMVD flag are all equal to 0    -   Merge flag is equal to 1    -   Current block is bi-predicted, and POC distance between current        picture and reference picture in list 1 is equal to the POC        distance between reference picture in list 0 and current picture    -   The current CU height is greater than or equal to 8    -   Number of luma samples (CU width*height) is greater than or        equal to 64        2.2.9.1.2 “Parametric Error Surface Equation” Based Sub-Pel        Refinement

The method is summarized below:

-   -   1. The parametric error surface fit is computed only if the        center position is the best cost position in a given iteration.    -   2. The center position cost and the costs at (−1,0), (0,−1),        (1,0) and (0,1) positions from the center are used to fit a 2-D        parabolic error surface equation of the form        E(x,y)=A(x−x ₀)² +B(y−y ₀)² +C    -   where (x₀,y₀) corresponds to the position with the least cost        and C corresponds to the minimum cost value. By solving the 5        equations in 5 unknowns, (x₀,y₀) is computed as:        x ₀=(E(−1,0)−E(1,0))/(2(E(−1,0)+E(1,0)−2E(0,0)))        y ₀=(E(0,−1)−E(0,1))/(2((E(0,−1)+E(0,1)−2E(0,0)))    -   (x₀,y₀) can be computed to any required sub-pixel precision by        adjusting the precision at which the division is performed (i.e.        how many bits of quotient are computed). For 1/16^(th)-pel        accuracy, just 4-bits in the absolute value of the quotient        needs to be computed, which lends itself to a fast-shifted        subtraction-based implementation of the 2 divisions required per        CU.    -   3. The computed (x₀,y₀) are added to the integer distance        refinement MV to get the sub-pixel accurate refinement delta MV.        2.3 Intra Block Copy

Intra block copy (IBC), a.k.a. current picture referencing, has beenadopted in HEVC Screen Content Coding extensions (HEVC-SCC) and thecurrent VVC test model (VTM-4.0). IBC extends the concept of motioncompensation from inter-frame coding to intra-frame coding. Asdemonstrated in FIG. 21. the current block is predicted by a referenceblock in the same picture when IBC is applied. The samples in thereference block must have been already reconstructed before the currentblock is coded or decoded. Although IBC is not so efficient for mostcamera-captured sequences, it shows significant coding gains for screencontent. The reason is that there are lots of repeating patterns, suchas icons and text characters in a screen content picture. IBC can removethe redundancy between these repeating patterns effectively. InHEVC-SCC, an inter-coded coding unit (CU) can apply IBC if it choosesthe current picture as its reference picture. The MV is renamed as blockvector (BV) in this case, and a BV always has an integer-pixelprecision. To be compatible with main profile HEVC, the current pictureis marked as a “long-term” reference picture in the Decoded PictureBuffer (DPB). It should be noted that similarly, in multiple view/3Dvideo coding standards, the inter-view reference picture is also markedas a “long-term” reference picture.

Following a BV to find its reference block, the prediction can begenerated by copying the reference block. The residual can be got bysubtracting the reference pixels from the original signals. Thentransform and quantization can be applied as in other coding modes.

However, when a reference block is outside of the picture, or overlapswith the current block, or outside of the reconstructed area, or outsideof the valid area restricted by some constrains, part or all pixelvalues are not defined. Basically, there are two solutions to handlesuch a problem. One is to disallow such a situation, e.g. in bitstreamconformance. The other is to apply padding for those undefined pixelvalues. The following sub-sessions describe the solutions in detail.

2.3.1 IBC in VVC Test Model (VTM4.0)

In the current VVC test model, i.e. VTM-4.0 design, the whole referenceblock should be with the current coding tree unit (CTU) and does notoverlap with the current block. Thus, there is no need to pad thereference or prediction block. The IBC flag is coded as a predictionmode of the current CU. Thus, there are totally three prediction modes,MODE_INTRA, MODE_INTER and MODE_IBC for each CU.

2.3.1.1 IBC Merge Mode

In IBC merge mode, an index pointing to an entry in the IBC mergecandidates list is parsed from the bitstream. The construction of theIBC merge list can be summarized according to the following sequence ofsteps:

-   -   Step 1: Derivation of spatial candidates    -   Step 2: Insertion of HMVP candidates    -   Step 3: Insertion of pairwise average candidates

In the derivation of spatial merge candidates, a maximum of four mergecandidates are selected among candidates located in the positionsdepicted in A₁, B₁, B₀, A₀ and B₂ as depicted in FIG. 2. The order ofderivation is A₁, B₁, B₀, A₀ and B₂. Position B₂ is considered only whenany PU of position A₁, B₁, B₀, A₀ is not available (e.g. because itbelongs to another slice or tile) or is not coded with IBC mode. Aftercandidate at position A₁ is added, the insertion of the remainingcandidates is subject to a redundancy check which ensures thatcandidates with same motion information are excluded from the list sothat coding efficiency is improved.

After insertion of the spatial candidates, if the IBC merge list size isstill smaller than the maximum IBC merge list size, IBC candidates fromHMVP table may be inserted. Redundancy check are performed wheninserting the HMVP candidates.

Finally, pairwise average candidates are inserted into the IBC mergelist.

When a reference block identified by a merge candidate is outside of thepicture, or overlaps with the current block, or outside of thereconstructed area, or outside of the valid area restricted by someconstrains, the merge candidate is called invalid merge candidate.

It is noted that invalid merge candidates may be inserted into the IBCmerge list.

2.3.1.2 IBC AMVP Mode

In IBC AMVP mode, an AMVP index point to an entry in the IBC AMVP listis parsed from the bitstream. The construction of the IBC AMVP list canbe summarized according to the following sequence of steps:

-   -   Step 1: Derivation of spatial candidates        -   Check A₀, A₁ until an available candidate is found.        -   Check B₀, B₁, B₂ until an available candidate is found.    -   Step 2: Insertion of HMVP candidates    -   Step 3: Insertion of zero candidates

After insertion of the spatial candidates, if the IBC AMVP list size isstill smaller than the maximum IBC AMVP list size, IBC candidates fromHMVP table may be inserted.

Finally, zero candidates are inserted into the IBC AMVP list.

2.3.1.3 Chroma IBC Mode

In the current VVC, the motion compensation in the chroma IBC mode isperformed at sub block level. The chroma block will be partitioned intoseveral sub blocks. Each sub block determines whether the correspondingluma block has a block vector and the validity if it is present. Thereis encoder constrain in the current VTM, where the chroma IBC mode willbe tested if all sub blocks in the current chroma CU have valid lumablock vectors. For example, on a YUV 420 video, the chroma block is N×Mand then the collocated luma region is 2N×2M. The sub block size of achroma block is 2×2. There are several steps to perform the chroma myderivation then the block copy process.

-   -   1) The chroma block will be first partitioned into (N>>1)*(M>>1)        sub blocks.    -   2) Each sub block with atop left sample coordinated at (x, y)        fetches the corresponding luma block covering the same top-left        sample which is coordinated at (2x, 2y).    -   3) The encoder checks the block vector (bv) of the fetched luma        block. If one of the following conditions is satisfied, the by        is considered as invalid.        -   a. A by of the corresponding luma block is not existing.        -   b. The prediction block identified by a by is not            reconstructed yet.        -   c. The prediction block identified by a by is partially or            fully overlapped with the current block.    -   4) The chroma motion vector of a sub block is set to the motion        vector of the corresponding luma sub block.

The IBC mode is allowed at the encoder when all sub blocks find a validbv.

2.3.2 Single BV list for IBC (in VTM5.0)

JVET-N0843 is adopted to the VVC. In the JVET-N0843, the BV predictorsfor merge mode and AMVP mode in IBC will share a common predictor list,which consist of the following elements:

-   -   2 spatial neighboring positions (A1, B1 as in FIG. 2)    -   5 HMVP entries    -   Zero vectors by default

The number of candidates in the list is controlled by a variable derivedfrom the slice header. For merge mode, up to first 6 entries of thislist will be used; for AMVP mode, the first 2 entries of this list willbe used. And the list conforms with the shared merge list regionrequirement (shared the same list within the SMR).

In addition to the above-mentioned BV predictor candidate list,JVET-N0843 also proposed to simplify the pruning operations between HMVPcandidates and the existing merge candidates (A1, B1). In thesimplification there will be up to 2 pruning operations since it onlycompares the first HMVP candidate with spatial merge candidate(s).

3. Problems

The current design of merge modes may have the following problems:

-   -   1. The regular merge list construction process depends on the        usage of TPM for the current block.        -   a. For TPM-coded blocks, full pruning is applied among            spatial merge candidates.        -   b. For non-TPM-coded blocks, partial pruning is applied            among spatial merge candidates.    -   2. According to current design, all merge related tools        (including IBC merge, regular merge, MMVD, sub-block merge,        CIIP, TPM) are signalled by one flag, named general_merge_flag.        However, it is possible that when this flag is true, all merge        related tools are signaled or to be derived to be disabled. How        to handle this case is unknown. In addition, it is disallowed to        turn off the merge mode, that is the maximum number of merge        candidate shall be unequal to 0. However, for high throughput        encoder/decoder, it may need to force disabling the merge mode.    -   3. The decision of initialized MV for ATMVP process is dependent        on slice type, all reference pictures' POC values,        collocated_from_l0_flag, etc. al, which delays the throughput of        MVs.    -   4. Derivation process of collocated MVs is dependent on the        usage of sub-block technology, such as the conventional TMVP        process or ATMVP process which requires additional logic.    -   5. For a sub-CU in ATMVP coded block, even its corresponding        collocated block is inter coded, it is possible the sub-CU's        motion information couldn't be derived from the corresponding        collocated block, but filled with other motion information. Such        design is sub-optimal for both coding efficiency and throughput.    -   6. The HEVC specification defines the availability of one        neighbouring block in current or reference picture based on        whether the block is constructed or in a different CTU row/slice        etc. al. However, in VVC, multiple coding methods have been        introduced. Different definitions of a block's availability may        need to be defined.

4. Examples of Techniques and Embodiments

The detailed listing below should be considered as examples to explaingeneral concepts. These embodiments should not be interpreted in anarrow way. Furthermore, these techniques can be combined in any manner.For example, the embodiments discussed in this document are applicableto geometry partition mode (GPM) in which the current video block ispartitioned into at least two non-rectangular sub-blocks. Thenon-rectangular blocks can be of any geometrical shape, other than arectangle. For example, the GPM comprises splitting the first videoblock into multiple prediction partitions to apply motion predictionseparately, and at least one partition having a non-rectangular shape.Further, although the embodiments herein are discussed using examples ofalternative temporal motion vector prediction coding (ATMVP), in someembodiments, sub-block based temporal motion vector predictor coding(SbTMVP) is also applicable.

The neighbouring blocks denoted as A0, A1, B0, B1, B2 etc. are shown inFIG. 2.

-   -   1. The regular merge list construction process for conventional        merge and TPM coded blocks is decoupled from the coding method        of the current block.        -   a. In one example, partial pruning is applied to spatial            merge candidates when TPM is applied to one block.            -   i. In one example, whether two candidates are compared                with each other are determined in the same way as that                used for a non-TPM merge coded blocks.            -   ii. In one example, B1 is compared to A1, B0 is compared                to B1, A0 is compared to A1, B2 is compared to B1 and                A1.            -   iii. Alternatively, full pruning is applied to spatial                merge candidates even TPM is not used for one block.            -   iv. Alternatively, furthermore, full pruning may be                applied to some specific block dimensions.                -   1. For example, full pruning may be applied to block                    dimensions wherein TPM is allowed.                -   2. For example, when a block size contains less than                    M*H samples, e.g., 16 or 32 or 64 luma samples, full                    pruning is not allowed.                -   3. For example, when a block's width >th1 or >=th1                    and/or a block's height >th2 or >=th2, full pruning                    is not allowed.        -   b. In one example, whether to check B2 is based on the            number of available merge candidates before checking B2 when            TPM is applied to one block.            -   i. Alternatively, B2 is always checked regardless the                number of available merge candidates for non-TPM merge                coded blocks.    -   2. The initialized MV used for identifying a block to determine        whether ATMVP is available or not may just rely on the list X        information of a spatial neighbouring block (e.g., A1), and X is        set to where the collocated picture used for temporal motion        vector prediction is derived from (e.g.,        collocated_from_l0_flag).        -   a. Alternatively, X is decided according to whether all            reference pictures in all reference lists are with smaller            POC values or no greater POC values compared to the current            picture.            -   i. In on example, if it is true, X is set to 1.                Otherwise, X is set to 0.        -   b. Alternatively, if the reference picture associated with            list X of a spatial neighbouring block (e.g., A1) is            available and has the same POC value as the col-located            picture, the initialized MV is set to the MV associated with            list X of the spatial neighbouring block. Otherwise, a            default MV (e.g., (0, 0)) is utilized.        -   c. Alternatively, motion information stored in HMVP table            may be used as the initialized MV in ATMVP.            -   i. For example, the first available motion information                stored in HMVP table may be used.            -   ii. For example, the first available motion information                stored in HMVP table that is associated with certain                reference picture (e.g., collocated picture) may be                used.        -   d. Alternatively, X is a fixed number, such as 0 or 1.    -   3. The derivation process of collocated MVs used for sub-block        based coding tools and non-sub-block based coding tools may be        aligned, i.e., the process is independent from the usage of a        certain coding tool.        -   a. In one example, the whole or partial of the derivation            process of collocated MVs for sub-block based coding tools            is aligned to that used for TMVP.            -   i. In one example, if it is uni-prediction from list Y,                the motion vector of list Y is scaled to a target                reference picture list X;            -   ii. In one example, if it is bi-prediction and the                target reference picture list is X, the motion vector of                list Y is scaled to the target reference picture list X,                and Y may be determined according to the following                rules:                -   If none of reference pictures has a greater POC                    values or all reference pictures have smaller POC                    values compared to current picture, Y is set equal                    to X.                -   Otherwise, Y is set equal to                    collocated_from_l0_flag.        -   b. In one example, the whole or partial of the derivation            process of collocated MVs for TMVP is aligned to that used            for sub-block-based coding tools.    -   4. The motion candidate list construction process (e.g., regular        merge list, IBC merge/AMVP list) may depend on the block        dimensions and/or merge sharing conditions. Denote a block's        width and height as W and H, respectively. Condition C may        depend on W and H and/or merge sharing conditions.        -   a. In one example, derivation of spatial merge candidates is            skipped if condition C is satisfied.        -   b. In one example, derivation of HMVP candidates is skipped            if condition C is satisfied.        -   c. In one example, derivation of pairwise merge candidates            is skipped if condition C is satisfied.        -   d. In one example, number of maximum pruning operations is            reduced or set to 0 if condition C is satisfied.        -   e. In one example, condition C is satisfied when W*H is            smaller or no larger than a threshold (e.g., 64 or 32).        -   f. In one example, condition C is satisfied when W and/or H            is smaller or no larger than a threshold (e.g., 4 or 8).        -   g. In one example, condition C is satisfied when the current            block is under a shared node.    -   5. The maximum number of allowed regular merge        candidates/maximum number of allowed IBC candidates/maximum        number of allowed sub-block merge candidates may be set to 0.        Therefore, certain tools may be disabled, and related syntax        elements are not needed to be signalled.        -   a. In one example, when the maximum number of allowed            regular merge candidates is equal to 0, a coding tool which            relies on regular merge list may be disabled. The coding            tool may be regular merge, MMVD, CIIP, TPM, DMVR etc. al.        -   b. In one example, when the maximum number of allowed IBC            candidates is equal to 0, IBC AMVP and/or IBC merge may be            disabled.        -   c. In one example, when the maximum number of allowed            sub-block based merge candidates is equal to 0, sub-block            based technologies, e.g., ATMVP, affine merge mode may be            disabled.        -   d. When a tool is disabled according to the maximum number            of allowed candidates, signaling of related syntax elements            is skipped.            -   i. Alternatively, furthermore, the signalling of merge                related tools may need to check whether the maximum                number of allowed candidates is unequal to 0.            -   ii. Alternatively, furthermore, invoking of a process                for the merge related tools may need to check whether                the maximum number of allowed candidates is unequal to                0.    -   6. The signalling of general_merge_flag and/or cu_skip_flag may        depend on the maximum number of allowed regular merge        candidates/maximum number of allowed IBC candidates/maximum        number of allowed sub-block merge candidates/usage of merge        related coding tools.        -   a. In one example, merge related coding tools may include            IBC merge, regular merge, MMVD, sub-block merge, CIIP, TPM,            DMVR and etc.        -   b. In one example, when the maximum number of allowed            regular merge candidates, the maximum number of allowed IBC            merge/AMVP candidates, the maximum number of allowed            sub-block merge candidate are equal to 0, the            general_merge_flag and/or cu_skip_flag is not signaled.            -   i. Alternatively, furthermore, general_merge_flag and/or                cu_skip_flag is inferred to be 0.    -   7. A conformance bitstream shall satisfy that at least one of        the merge related tools including IBC merge, regular merge,        MMVD, sub-block merge, CIIP, TPM, DMVR and etc. is enabled when        the general_merge_flag or cu_skip_flag of the current block is        true.    -   8. A conformance bitstream shall satisfy that at least one of        the merge related tools including regular merge, MMVD, sub-block        merge, CIIP, TPM, DMVR and etc. is enabled when the        (general_merge_flag or cu_skip_flag) of the current block is        true and IBC is disabled for one        slice/tile/brick/picture/current block.    -   9. A conformance bitstream shall satisfy that at least one of        the merge related tools including IBC merge, regular merge,        sub-block merge, CIIP, TPM is enabled when the        (general_merge_flag or cu_skip_flag) of the current block is        true and MMVD is disabled for one        slice/tile/brick/picture/current block.    -   10. A conformance bitstream shall satisfy that at least one of        the merge related tools including IBC merge, regular merge,        MMVD, sub-block merge, TPM is enabled when the        (general_merge_flag or cu_skip_flag) of the current block is        true and CIIP is disabled for one        slice/tile/brick/picture/current block.    -   11. A conformance bitstream shall satisfy that at least one of        the merge related tools including IBC merge, regular merge,        MMVD, sub-block merge, CIIP is enabled when the        (general_merge_flag or cu_skip_flag) of the current block is        true and TPM is disabled for one        slice/tile/brick/picture/current block.    -   12. A conformance bitstream shall satisfy that at least one of        the enabled merge related tools including IBC merge, regular        merge, MMVD, sub-block merge, CIIP, TPM is applied when the        general_merge_flag or cu_skip_flag of the current block is true.        When coding a first block, the check of availability of a 2^(nd)        block may depend on the coded mode information of the first        block, for example, if different modes are used in the 1^(st)        and 2^(nd) block, the 2^(nd) block may be treated as unavailable        even regardless of other condition checking results (e.g., has        been constructed).        -   a. In one example, when 1^(st) block is inter coded and            2^(nd) block is IBC code, 2^(nd) block is marked as            unavailable.        -   b. In one example, when 1^(st) block is IBC coded and 2^(nd)            block is inter code, 2^(nd) block is marked as unavailable.        -   c. When the 2^(nd) is marked as unavailable, the related            coded information (e.g., motion information) is disallowed            to be utilized for coding the 1^(st) block.

5. Embodiment

The suggested changes on top of the latest VVC working draft (JVET-N1001v7) are given as follows. The deleted text is marked with boldedcapitalized font. The newly added parts are highlighted in bolded,underlined, italicized font.

5.1 Embodiment #1

This embodiment is to align the pruning process for non-TPM coded blockto that for TPM coded blocks i.e., full pruning operations for non-TPMcoded blocks.

8.5.2.3 Derivation Process for Spatial Merging Candidates

Inputs to this process are:

-   -   a luma location (xCb, yCb) of the top-left sample of the current        luma coding block relative to the top-left luma sample of the        current picture,    -   a variable cbWidth specifying the width of the current coding        block in luma samples,    -   a variable cbHeight specifying the height of the current coding        block in luma samples.

Outputs of this process are as follows, with X being 0 or 1:

-   -   the availability flags availableFlagA₀, availableFlagA₁,        availableFlagB₀, availableFlagB₁ and availableFlagB₂ of the        neighbouring coding units,    -   the reference indices refIdxLXA₀, refIdxLXA₁, refIdxLXB₀,        refIdxLXB₁ and refIdxLXB₂ of the neighbouring coding units,    -   the prediction list utilization flags predFlagLXA₀,        predFlagLXA₁, predFlagLXB₀, predFlagLXB₁ and predFlagLXB₂ of the        neighbouring coding units,    -   the motion vectors in 1/16 fractional-sample accuracy mvLXA₀,        mvLXA₁, mvLXB₀, mvLXB₁ and mvLXB₂ of the neighbouring coding        units,    -   the bi-prediction weight indices gbiIdxA₀, gbiIdxA₁, gbiIdxB₀,        gbiIdxB₁, and gbiIdxB₂.

For the derivation of availableFlagA₁, refIdxLXA₁, predFlagLXA₁ andmvLXA₁ the following applies:

-   -   The luma location (xNbA₁, yNbA₁) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbHeight−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbA₁, yNbA₁) as inputs, and the output is assigned to        the block availability flag availableA₁.    -   The variables availableFlagA₁, refIdxLXA₁, predFlagLXA₁ and        mvLXA₁ are derived as follows:        -   If availableA₁ is equal to FALSE, availableFlagA₁ is set            equal to 0, both components of mvLXA₁ are set equal to 0,            refIdxLXA₁ is set equal to −1 and predFlagLXA₁ is set equal            to 0, with X being 0 or 1, and gbiIdxA₁ is set equal to 0.        -   Otherwise, availableFlagA₁ is set equal to 1 and the            following assignments are made:            mvLXA ₁=MvLX[xNbA ₁][yNbA ₁]  (8-294)            refIdxLXA ₁=RefIdxLX[xNbA ₁][yNbA ₁]  (8-295)            predFlagLXA ₁=PredFlagLX[xNbA ₁][yNbA ₁]  (8-296)            gbiIdxA ₁=GbiIdx[xNbA ₁][yNbA ₁]  (8-297)

For the derivation of availableFlagB₁, refIdxLXB₁, predFlagLXB₁ andmvLXB₁ the following applies:

-   -   The luma location (xNbB₁, yNbB1) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth−1, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₁, yNbB1) as inputs, and the output is assigned to        the block availability flag availableB₁.    -   The variables availableFlagB₁, refIdxLXB₁, predFlagLXB₁ and        mvLXB₁ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₁ is set equal to 0, both components of mvLXB₁            are set equal to 0, refIdxLXB₁ is set equal to −1 and            predFlagLXB₁ is set equal to 0, with X being 0 or 1, and            gbiIdxB₁ is set equal to 0:            -   availableB₁ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbB₁, yNbB1) have the same motion                vectors and the same reference indices.        -   Otherwise, availableFlagB₁ is set equal to 1 and the            following assignments are made:            mvLXB ₁=MvLX[xNbB ₁][yNbB1]  (8-298)            refIdxLXB ₁=RefIdxLX[xNbB ₁][yNbB1]  (8-299)            predFlagLXB ₁=PredFlagLX[xNbB ₁][yNbB1]  (8-300)            gbiIdxB ₁=GbiIdx[xNbB ₁][yNbB1]  (8-301)

For the derivation of availableFlagB₀, refIdxLXB₀, predFlagLXB₀ andmvLXB₀ the following applies:

-   -   The luma location (xNbB₀, yNbB₀) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₀, yNbB₀) as inputs, and the output is assigned to        the block availability flag availableB₀.    -   The variables availableFlagB₀, refIdxLXB₀, predFlagLXB₀ and        mvLXB₀ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₀ is set equal to 0, both components of mvLXB₀            are set equal to 0, refIdxLXB₀ is set equal to −1 and            predFlagLXB₀ is set equal to 0, with X being 0 or 1, and            gbiIdxB₀ is set equal to 0:            -   availableB₀ is equal to FALSE.            -   availableB₁ is equal to TRUE and the luma locations                (xNbB₁, yNbB1) and (xNbB₀, yNbB₀) have the same motion                vectors and the same reference indices.            -   availableA₁ is equal to TRUE, the luma locations (xNbA₁,                yNbA₁) and (xNbB₀, yNbB₀) have the same motion vectors                and the same reference indices AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.        -   Otherwise, availableFlagB₀ is set equal to 1 and the            following assignments are made:            mvLXB ₀=MvLX[xNbB ₀][yNbB ₀]  (8-302)            refIdxLXB ₀=RefIdxLX[xNbB ₀][yNbB ₀]  (8-303)            predFlagLXB ₀=PredFlagLX[xNbB ₀][yNbB ₀]  (8-304)            gbiIdxB ₀=GbiIdx[xNbB ₀][yNbB ₀]  (8-305)

For the derivation of availableFlagA₀, refIdxLXA₀, predFlagLXA₀ andmvLXA₀ the following applies:

-   -   The luma location (xNbA₀, yNbA₀) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbWidth).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbA₀, yNbA₀) as inputs, and the output is assigned to        the block availability flag availableA₀.    -   The variables availableFlagA₀, refIdxLXA₀, predFlagLXA₀ and        mvLXA₀ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagA₀ is set equal to 0, both components of mvLXA₀            are set equal to 0, refIdxLXA₀ is set equal to −1 and            predFlagLXA₀ is set equal to 0, with X being 0 or 1, and            gbiIdxA₀ is set equal to 0:            -   availableA₀ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbA₀, yNbA₀) have the same motion                vectors and the same reference indices.            -   availableB₁ is equal to TRUE, the luma locations (xNbB₁,                yNbB1) and (xNbA₀, yNbA₀) have the same motion vectors                and the same reference indices AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.            -   availableB₀ is equal to TRUE, the luma locations (xNbB₀,                yNbB₀) and (xNbA₀, yNbA₀) have the same motion vectors                and the same reference indices AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.        -   Otherwise, availableFlagA₀ is set equal to 1 and the            following assignments are made:            mvLXA ₀=MvLX[xNbA ₀][yNbA ₀]  (8-306)            refIdxLXA ₀=RefIdxLX[xNbA ₀][yNbA ₀]  (8-307)            predFlagLXA ₀=PredFlagLX[xNbA ₀][yNbA ₀]  (8-308)            gbiIdxA ₀=GbiIdx[xNbA ₀][yNbA ₀]  (8-309)

For the derivation of availableFlagB₂, refIdxLXB₂, predFlagLXB₂ andmvLXB₂ the following applies:

-   -   The luma location (xNbB₂, yNbB₂) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₂, yNbB₂) as inputs, and the output is assigned to        the block availability flag availableB₂.    -   The variables availableFlagB₂, refIdxLXB₂, predFlagLXB₂ and        mvLXB₂ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₂ is set equal to 0, both components of mvLXB₂            are set equal to 0, refIdxLXB₂ is set equal to −1 and            predFlagLXB₂ is set equal to 0, with X being 0 or 1, and            gbiIdxB₂ is set equal to 0:            -   availableB₂ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₁ is equal to TRUE and the luma locations                (xNbB₁, yNbB1) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₀ is equal to TRUE, the luma locations (xNbB₀,                yNbB₀) and (xNbB₂, yNbB₂) have the same motion vectors                and the same reference indices AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.            -   availableA₀ is equal to TRUE, the luma locations (xNbA₀,                yNbA₀) and (xNbB₂, yNbB₂) have the same motion vectors                and the same reference indices AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.            -   availableFlagA₀+availableFlagA₁+availableFlagB₀+availableFlagB₁                is equal to 4 and merge_triangle_flag[xCb][yCb] is equal                to 0.        -   Otherwise, availableFlagB₂ is set equal to 1 and the            following assignments are made:            mvLXB ₂=MvLX[xNbB ₂][yNbB ₂]  (8-310)            refIdxLXB ₂=RefIdxLX[xNbB ₂][yNbB ₂]  (8-311)            predFlagLXB ₂=PredFlagLX[xNbB ₂][yNbB ₂]  (8-312)            gbiIdxB ₂=GbiIdx[xNbB ₂][yNbB ₂]  (8-313)

5.2 Embodiment #2

This embodiment is to align the pruning process for TPM coded block tothat for non-TPM coded blocks, i.e., limited pruning operations for TPMcoded blocks.

8.5.2.3 Derivation Process for Spatial Merging Candidates

Inputs to this process are:

-   -   a luma location (xCb, yCb) of the top-left sample of the current        luma coding block relative to the top-left luma sample of the        current picture,    -   a variable cbWidth specifying the width of the current coding        block in luma samples,    -   a variable cbHeight specifying the height of the current coding        block in luma samples.

Outputs of this process are as follows, with X being 0 or 1:

-   -   the availability flags availableFlagA₀, availableFlagA₁,        availableFlagB₀, availableFlagB₁ and availableFlagB₂ of the        neighbouring coding units,    -   the reference indices refIdxLXA₀, refIdxLXA₁, refIdxLXB₀,        refIdxLXB₁ and refIdxLXB₂ of the neighbouring coding units,    -   the prediction list utilization flags predFlagLXA₀,        predFlagLXA₁, predFlagLXB₀, predFlagLXB₁ and predFlagLXB₂ of the        neighbouring coding units,    -   the motion vectors in 1/16 fractional-sample accuracy mvLXA₀,        mvLXA₁, mvLXB₀, mvLXB₁ and mvLXB₂ of the neighbouring coding        units,    -   the bi-prediction weight indices gbiIdxA₀, gbiIdxA₁, gbiIdxB₀,        gbiIdxB₁, and gbiIdxB₂.

For the derivation of availableFlagA₁, refIdxLXA₁, predFlagLXA₁ andmvLXA₁ the following applies:

-   -   The luma location (xNbA₁, yNbA₁) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbHeight−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbA₁, yNbA₁) as inputs, and the output is assigned to        the block availability flag availableA₁.    -   The variables availableFlagA₁, refIdxLXA₁, predFlagLXA₁ and        mvLXA₁ are derived as follows:        -   If availableA₁ is equal to FALSE, availableFlagA₁ is set            equal to 0, both components of mvLXA₁ are set equal to 0,            refIdxLXA₁ is set equal to −1 and predFlagLXA₁ is set equal            to 0, with X being 0 or 1, and gbiIdxA₁ is set equal to 0.        -   Otherwise, availableFlagA₁ is set equal to 1 and the            following assignments are made:            mvLXA ₁=MvLX[xNbA ₁][yNbA ₁]  (8-294)            refIdxLXA ₁=RefIdxLX[xNbA ₁][yNbA ₁]  (8-295)            predFlagLXA ₁=PredFlagLX[xNbA ₁][yNbA ₁]  (8-296)            gbiIdxA ₁=GbiIdx[xNbA ₁][yNbA ₁]  (8-297)

For the derivation of availableFlagB₁, refIdxLXB₁, predFlagLXB₁ andmvLXB₁ the following applies:

-   -   The luma location (xNbB₁, yNbB1) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth−1, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₁, yNbB1) as inputs, and the output is assigned to        the block availability flag availableB₁.    -   The variables availableFlagB₁, refIdxLXB₁, predFlagLXB₁ and        mvLXB₁ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₁ is set equal to 0, both components of mvLXB₁            are set equal to 0, refIdxLXB₁ is set equal to −1 and            predFlagLXB₁ is set equal to 0, with X being 0 or 1, and            gbiIdxB₁ is set equal to 0:            -   availableB₁ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbB₁, yNbB1) have the same motion                vectors and the same reference indices.        -   Otherwise, availableFlagB₁ is set equal to 1 and the            following assignments are made:            mvLXB ₁=MvLX[xNbB ₁][yNbB1]  (8-298)            refIdxLXB ₁=RefIdxLX[xNbB ₁][yNbB1]  (8-299)            predFlagLXB ₁=PredFlagLX[xNbB ₁][yNbB1]  (8-300)            gbiIdxB ₁=GbiIdx[xNbB ₁][yNbB1]  (8-301)

For the derivation of availableFlagB₀, refIdxLXB₀, predFlagLXB₀ andmvLXB₀ the following applies:

-   -   The luma location (xNbB₀, yNbB₀) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₀, yNbB₀) as inputs, and the output is assigned to        the block availability flag availableB₀.    -   The variables availableFlagB₀, refIdxLXB₀, predFlagLXB₀ and        mvLXB₀ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₀ is set equal to 0, both components of mvLXB₀            are set equal to 0, refIdxLXB₀ is set equal to −1 and            predFlagLXB₀ is set equal to 0, with X being 0 or 1, and            gbiIdxB₀ is set equal to 0:            -   availableB₀ is equal to FALSE.            -   availableB₁ is equal to TRUE and the luma locations                (xNbB₁, yNbB1) and (xNbB₀, yNbB₀) have the same motion                vectors and the same reference indices.            -   AVAILABLEA1 IS EQUAL TO TRUE, THE LUMA LOCATIONS (XNBA1,                YNBA1) AND (XNBB0, YNBB0) HAVE THE SAME MOTION VECTORS                AND THE SAME REFERENCE INDICES AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.        -   Otherwise, availableFlagB₀ is set equal to 1 and the            following assignments are made:            mvLXB ₀=MvLX[xNbB ₀][yNbB ₀]  (8-302)            refIdxLXB ₀=RefIdxLX[xNbB ₀][yNbB ₀]  (8-303)            predFlagLXB ₀=PredFlagLX[xNbB ₀][yNbB ₀]  (8-304)            gbiIdxB ₀=GbiIdx[xNbB ₀][wyNbB₀]  (8-305)

For the derivation of availableFlagA₀, refIdxLXA₀, predFlagLXA₀ andmvLXA₀ the following applies:

-   -   The luma location (xNbA₀, yNbA₀) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbWidth).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbA₀, yNbA₀) as inputs, and the output is assigned to        the block availability flag availableA₀.    -   The variables availableFlagA₀, refIdxLXA₀, predFlagLXA₀ and        mvLXA₀ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagA₀ is set equal to 0, both components of mvLXA₀            are set equal to 0, refIdxLXA₀ is set equal to −1 and            predFlagLXA₀ is set equal to 0, with X being 0 or 1, and            gbiIdxA₀ is set equal to 0:            -   availableA₀ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbA₀, yNbA₀) have the same motion                vectors and the same reference indices.            -   AVAILABLEB1 IS EQUAL TO TRUE, THE LUMA LOCATIONS (XNBB1,                YNBB1) AND (XNBA0, YNBA0) HAVE THE SAME MOTION VECTORS                AND THE SAME REFERENCE INDICES AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.            -   AVAILABLEB0 IS EQUAL TO TRUE, THE LUMA LOCATIONS (XNBB0,                YNBB0) AND (XNBA0, YNBA0) HAVE THE SAME MOTION VECTORS                AND THE SAME REFERENCE INDICES AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.        -   Otherwise, availableFlagA₀ is set equal to 1 and the            following assignments are made:            mvLXA ₀=MvLX[xNbA ₀][yNbA ₀]  (8-306)            refIdxLXA ₀=RefIdxLX[xNbA ₀][yNbA ₀]  (8-307)            predFlagLXA ₀=PredFlagLX[xNbA ₀][yNbA ₀]  (8-308)            gbiIdxA ₀=GbiIdx[xNbA ₀][yNbA ₀]  (8-309)

For the derivation of availableFlagB₂, refIdxLXB₂, predFlagLXB₂ andmvLXB₂ the following applies:

-   -   The luma location (xNbB₂, yNbB₂) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₂, yNbB₂) as inputs, and the output is assigned to        the block availability flag availableB₂.    -   The variables availableFlagB₂, refIdxLXB₂, predFlagLXB₂ and        mvLXB₂ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₂ is set equal to 0, both components of mvLXB₂            are set equal to 0, refIdxLXB₂ is set equal to −1 and            predFlagLXB₂ is set equal to 0, with X being 0 or 1, and            gbiIdxB₂ is set equal to 0:            -   availableB₂ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₁ is equal to TRUE and the luma locations                (xNbB₁, yNbB1) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   AVAILABLEB0 IS EQUAL TO TRUE, THE LUMA LOCATIONS (XNBB0,                YNBB0) AND (XNBB2, YNBB2) HAVE THE SAME MOTION VECTORS                AND THE SAME REFERENCE INDICES AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.            -   AVAILABLEA0 IS EQUAL TO TRUE, THE LUMA LOCATIONS (XNBA0,                YNBA0) AND (XNBB2, YNBB2) HAVE THE SAME MOTION VECTORS                AND THE SAME REFERENCE INDICES AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 1.            -   availableFlagA₀+availableFlagA₁+availableFlagB₀+availableFlagB₁                is equal to 4 and merge_triangle_flag[xCb][yCb] is equal                to 0.        -   Otherwise, availableFlagB₂ is set equal to 1 and the            following assignments are made:            mvLXB ₂=MvLX[xNbB ₂][yNbB ₂]  (8-310)            refIdxLXB ₂=RefIdxLX[xNbB ₂][yNbB ₂]  (8-311)            predFlagLXB ₂=PredFlagLX[xNbB ₂][yNbB ₂]  (8-312)            gbiIdxB ₂=GbiIdx[xNbB ₂][yNbB ₂]  (8-313)

5.3 Embodiment #3

This embodiment is to align the conditions for invoking the checking ofB2.

8.5.2.3 Derivation Process for Spatial Merging Candidates

Inputs to this process are:

-   -   a luma location (xCb, yCb) of the top-left sample of the current        luma coding block relative to the top-left luma sample of the        current picture,    -   a variable cbWidth specifying the width of the current coding        block in luma samples,    -   a variable cbHeight specifying the height of the current coding        block in luma samples.

Outputs of this process are as follows, with X being 0 or 1:

-   -   the availability flags availableFlagA₀, availableFlagA₁,        availableFlagB₀, availableFlagB₁ and availableFlagB₂ of the        neighbouring coding units,    -   the reference indices refIdxLXA₀, refIdxLXA₁, refIdxLXB₀,        refIdxLXB₁ and refIdxLXB₂ of the neighbouring coding units,    -   the prediction list utilization flags predFlagLXA₀,        predFlagLXA₁, predFlagLXB₀, predFlagLXB₁ and predFlagLXB₂ of the        neighbouring coding units,    -   the motion vectors in 1/16 fractional-sample accuracy mvLXA₀,        mvLXA₁, mvLXB₀, mvLXB₁ and mvLXB₂ of the neighbouring coding        units,    -   the bi-prediction weight indices gbiIdxA₀, gbiIdxA₁, gbiIdxB₀,        gbiIdxB₁, and gbiIdxB₂.

For the derivation of availableFlagA₁, refIdxLXA₁, predFlagLXA₁ andmvLXA₁ the following applies:

-   -   The luma location (xNbA₁, yNbA₁) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbHeight−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbA₁, yNbA₁) as inputs, and the output is assigned to        the block availability flag availableA₁.    -   The variables availableFlagA₁, refIdxLXA₁, predFlagLXA₁ and        mvLXA₁ are derived as follows:        -   . . .

For the derivation of availableFlagB₁, refIdxLXB₁, predFlagLXB₁ andmvLXB₁ the following applies:

-   -   The luma location (xNbB₁, yNbB1) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth−1, yCb−1).        -   . . .

For the derivation of availableFlagB₀, refIdxLXB₀, predFlagLXB₀ andmvLXB₀ the following applies:

-   -   The luma location (xNbB₀, yNbB₀) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth, yCb−1).        -   . . .

For the derivation of availableFlagA₀, refIdxLXA₀, predFlagLXA₀ andmvLXA₀ the following applies:

-   -   The luma location (xNbA₀, yNbA₀) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbWidth).        -   . . .

For the derivation of availableFlagB₂, refIdxLXB₂, predFlagLXB₂ andmvLXB₂ the following applies:

-   -   The luma location (xNbB₂, yNbB₂) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₂, yNbB₂) as inputs, and the output is assigned to        the block availability flag availableB₂.    -   The variables availableFlagB₂, refIdxLXB₂, predFlagLXB₂ and        mvLXB₂ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₂ is set equal to 0, both components of mvLXB₂            are set equal to 0, refIdxLXB₂ is set equal to −1 and            predFlagLXB₂ is set equal to 0, with X being 0 or 1, and            gbiIdxB₂ is set equal to 0:            -   availableB₂ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₁ is equal to TRUE and the luma locations                (xNbB₁, yNbB1) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₀ is equal to TRUE, the luma locations (xNbB₀,                yNbB₀) and (xNbB₂, yNbB₂) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.            -   availableA₀ is equal to TRUE, the luma locations (xNbA₀,                yNbA₀) and (xNbB₂, yNbB₂) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.            -   availableFlagA₀+availableFlagA₁+availableFlagB₀+availableFlagB₁                is equal to 4 AND MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL                TO 0.        -   Otherwise, availableFlagB₂ is set equal to 1 and the            following assignments are made:            mvLXB ₂=MvLX[xNbB ₂][yNbB ₂]  (8-310)            refIdxLXB ₂=RefIdxLX[xNbB ₂][yNbB ₂]  (8-311)            predFlagLXB ₂=PredFlagLX[xNbB ₂][yNbB ₂]  (8-312)            gbiIdxB ₂=GbiIdx[xNbB ₂][yNbB ₂]  (8-313)

5.4 Embodiment #4

This embodiment is to align the conditions for invoking the checking ofB2.

8.5.2.3 Derivation Process for Spatial Merging Candidates

Inputs to this process are:

-   -   a luma location (xCb, yCb) of the top-left sample of the current        luma coding block relative to the top-left luma sample of the        current picture,    -   a variable cbWidth specifying the width of the current coding        block in luma samples,    -   a variable cbHeight specifying the height of the current coding        block in luma samples.

Outputs of this process are as follows, with X being 0 or 1:

-   -   the availability flags availableFlagA₀, availableFlagA₁,        availableFlagB₀, availableFlagB₁ and availableFlagB₂ of the        neighbouring coding units,    -   the reference indices refIdxLXA₀, refIdxLXA₁, refIdxLXB₀,        refIdxLXB₁ and refIdxLXB₂ of the neighbouring coding units,    -   the prediction list utilization flags predFlagLXA₀,        predFlagLXA₁, predFlagLXB₀, predFlagLXB₁ and predFlagLXB₂ of the        neighbouring coding units,    -   the motion vectors in 1/16 fractional-sample accuracy mvLXA₀,        mvLXA₁, mvLXB₀, mvLXB₁ and mvLXB₂ of the neighbouring coding        units,    -   the bi-prediction weight indices gbiIdxA₀, gbiIdxA₁, gbiIdxB₀,        gbiIdxB₁, and gbiIdxB₂.

For the derivation of availableFlagA₁, refIdxLXA₁, predFlagLXA₁ andmvLXA₁ the following applies:

-   -   The luma location (xNbA₁, yNbA₁) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbHeight−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbA₁, yNbA₁) as inputs, and the output is assigned to        the block availability flag availableA₁.    -   The variables availableFlagA₁, refIdxLXA₁, predFlagLXA₁ and        mvLXA₁ are derived as follows:        -   . . .

For the derivation of availableFlagB₁, refIdxLXB₁, predFlagLXB₁ andmvLXB₁ the following applies:

-   -   The luma location (xNbB₁, yNbB1) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth−1, yCb−1).        -   . . .

For the derivation of availableFlagB₀, refIdxLXB₀, predFlagLXB₀ andmvLXB₀ the following applies:

-   -   The luma location (xNbB₀, yNbB₀) inside the neighbouring luma        coding block is set equal to (xCb+cbWidth, yCb−1).        -   . . .

For the derivation of availableFlagA₀, refIdxLXA₀, predFlagLXA₀ andmvLXA₀ the following applies:

-   -   The luma location (xNbA₀, yNbA₀) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb+cbWidth).        -   . . .

For the derivation of availableFlagB₂, refIdxLXB₂, predFlagLXB₂ andmvLXB₂ the following applies:

-   -   The luma location (xNbB₂, yNbB₂) inside the neighbouring luma        coding block is set equal to (xCb−1, yCb−1).    -   The availability derivation process for a block as specified in        clause 6.4.X [Ed. (BB): Neighbouring blocks availability        checking process tbd] is invoked with the current luma location        (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma        location (xNbB₂, yNbB₂) as inputs, and the output is assigned to        the block availability flag availableB₂.    -   The variables availableFlagB₂, refIdxLXB₂, predFlagLXB₂ and        mvLXB₂ are derived as follows:        -   If one or more of the following conditions are true,            availableFlagB₂ is set equal to 0, both components of mvLXB₂            are set equal to 0, refIdxLXB₂ is set equal to −1 and            predFlagLXB₂ is set equal to 0, with X being 0 or 1, and            gbiIdxB₂ is set equal to 0:            -   availableB₂ is equal to FALSE.            -   availableA₁ is equal to TRUE and the luma locations                (xNbA₁, yNbA₁) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₁ is equal to TRUE and the luma locations                (xNbB₁, yNbB1) and (xNbB₂, yNbB₂) have the same motion                vectors and the same reference indices.            -   availableB₀ is equal to TRUE, the luma locations (xNbB₀,                yNbB₀) and (xNbB₂, yNbB₂) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.            -   availableA₀ is equal to TRUE, the luma locations (xNbA₀,                yNbA₀) and (xNbB₂, yNbB₂) have the same motion vectors                and the same reference indices and                merge_triangle_flag[xCb][yCb] is equal to 1.            -   AVAILABLEFLAGA0+AVAILABLEFLAGA1+AVAILABLEFLAGB0+AVAIL                ABLEFLAGB1 IS EQUAL TO 4 AND                MERGE_TRIANGLE_FLAG[XCB][YCB] IS EQUAL TO 0.        -   Otherwise, availableFlagB₂ is set equal to 1 and the            following assignments are made:            mvLXB ₂=MvLX[xNbB ₂][yNbB ₂]  (8-310)            refIdxLXB ₂=RefIdxLX[xNbB ₂][yNbB ₂]  (8-311)            predFlagLXB ₂=PredFlagLX[xNbB ₂][yNbB ₂]  (8-312)            gbiIdxB ₂=GbiIdx[xNbB ₂][yNbB ₂]  (8-313)

5.5 Embodiment #5

This embodiment is to simplify the decision of initialized MV in ATMVPprocess.

8.5.5.4 Derivation Process for Subblock-Based Temporal Merging BaseMotion Data

Inputs to this process are:

-   -   the location (xCtb, yCtb) of the top-left sample of the luma        coding tree block that contains the current coding block,    -   the location (xColCtrCb, yColCtrCb) of the top-left sample of        the collocated luma coding block that covers the below-right        center sample.    -   the availability flag availableFlagA₁ of the neighbouring coding        unit,    -   the reference index refIdxLXA₁ of the neighbouring coding unit,    -   the prediction list utilization flag predFlagLXA₁ of the        neighbouring coding unit,    -   the motion vector in 1/16 fractional-sample accuracy mvLXA₁ of        the neighbouring coding unit.

Outputs of this process are:

-   -   the motion vectors ctrMvL0 and ctrMvL1,    -   the prediction list utilization flags ctrPredFlagL0 and        ctrPredFlagL1,    -   the temporal motion vector tempMv.

The variable tempMv is set as follows:tempMv[0]=0  (8-529)tempMv[1]=0  (8-530)

The variable currPic specifies the current picture.

When availableFlagA₁ is equal to TRUE, the following applies:

Set a variable X to collocated from l0 flag.

If predFlagLXA1 is equal to 1 and DiffPicOrderCnt(ColPic,RefPicList[X][refIdxLXA1]) is equal to 0 are true, tempMv is set equalto mvLXA1.

-   -   IF ALL OF THE FOLLOWING CONDITIONS ARE TRUE, TEMPMV IS SET EQUAL        TO MVL1A1:        -   PREDFLAGL1A1 IS EQUAL TO 1,        -   DIFFPICORDERCNT(COLPIC, REFPICLIST[1][REFIDXL1A1]) IS EQUAL            TO 0,        -   DIFFPICORDERCNT(APIC, CURRPIC) IS LESS THAN OR EQUAL TO 0            FOR EVERY PICTURE APIC IN EVERY REFERENCE PICTURE LIST OF            THE CURRENT SLICE,        -   SLICE_TYPE IS EQUAL TO B,        -   COLLOCATED_FROM_L0_FLAG IS EQUAL TO 0.    -   OTHERWISE IF ALL OF THE FOLLOWING CONDITIONS ARE TRUE, TEMPMV IS        SET EQUAL TO MVL0A1:        -   PREDFLAGLOA1 IS EQUAL TO 1,        -   DIFFPICORDERCNT(COLPIC, REFPICLIST[0][REFIDXL0A1]) IS EQUAL            TO 0.

The location (xColCb, yColCb) of the collocated block inside ColPic isderived as follows.xColCb=Clip3(xCtb,Min(CurPicWidthInSamplesY−1,xCtb+(1<<CtbLog2SizeY)+3),xColCtrCb+(tempMv[0]>>4))  (8-531)yColCb=Clip3(yCtb,Min(CurPicHeightInSamplesY−1,yCtb+(1<<CtbLog2SizeY)−1),yColCtrCb+(tempMv[1]>>4))  (8-532)

The array colPredMode is set equal to the prediction mode arrayCuPredMode of the collocated picture specified by ColPic.

The motion vectors ctrMvL0 and ctrMvL1, and the prediction listutilization flags ctrPredFlagL0 and ctrPredFlagL1 are derived asfollows:

. . .

5.6 Embodiment #6

Examples for alignment of derivation process of collocated MVs forsub-block and non-sub-block based methods.

8.5.2.12 Derivation Process for Collocated Motion Vectors

Inputs to this process are:

-   -   a variable currCb specifying the current coding block,    -   a variable colCb specifying the collocated coding block inside        the collocated picture specified by ColPic,    -   a luma location (xColCb, yColCb) specifying the top-left sample        of the collocated luma coding block specified by colCb relative        to the top-left luma sample of the collocated picture specified        by ColPic,    -   a reference index refIdxLX, with X being 0 or 1,    -   a flag indicating a subblock temporal merging candidate sbFlag.

Outputs of this process are:

-   -   the motion vector prediction mvLXCol in 1/16 fractional-sample        accuracy,    -   the availability flag availableFlagLXCol.

The variable currPic specifies the current picture.

The arrays predFlagL0Col[x][y], mvL0Col[x][y] and refIdxL0Col[x][y] areset equal to PredFlagL0[x][y], MvDmvrL0[x][y] and RefIdxL0[x][y],respectively, of the collocated picture specified by ColPic, and thearrays predFlagL1 Col[x][y], mvL1Col[x][y] and refIdxL1Col[x][y] are setequal to PredFlagL1[x][y], MvDmvrL1[x][y] and RefIdxL1[x][y],respectively, of the collocated picture specified by ColPic.

The variables mvLXCol and availableFlagLXCol are derived as follows:

-   -   If colCb is coded in an intra or IBC prediction mode, both        components of mvLXCol are set equal to 0 and availableFlagLXCol        is set equal to 0.    -   Otherwise, the motion vector mvCol, the reference index        refIdxCol and the reference list identifier listCol are derived        as follows:        -   If SBFLAG IS EQUAL TO 0, availableFlagLXCol is set to 1 and            the following applies:            -   If predFlagL0Col[xColCb][yColCb] is equal to 0, mvCol,                refIdxCol and listCol are set equal to                mvL1Col[xColCb][yColCb], refIdxL1Col[xColCb][yColCb] and                L1, respectively.            -   Otherwise, if predFlagL0Col[xColCb][yColCb] is equal to                1 and predFlagL1Col[xColCb][yColCb] is equal to 0,                mvCol, refIdxCol and listCol are set equal to                mvL0Col[xColCb][yColCb], refIdxL0Col[xColCb][yColCb] and                L0, respectively.            -   Otherwise (predFlagL0Col[xColCb][yColCb] is equal to 1                and predFlagL1Col[xColCb][yColCb] is equal to 1), the                following assignments are made:                -   If NoBackwardPredFlag is equal to 1, mvCol,                    refIdxCol and listCol are set equal to                    mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb]                    and LX, respectively.                -   Otherwise, mvCol, refIdxCol and listCol are set                    equal to mvLNCol[xColCb][yColCb],                    refIdxLNCol[xColCb][yColCb] and LN, respectively,                    with N being the value of collocated_from_l0_flag.        -   OTHERWISE (SBFLAG IS EQUAL TO 1), THE FOLLOWING APPLIES:            -   IF PREDFLAGLXCOL[XCOLCB][YCOLCB] IS EQUAL TO 1, MVCOL,                REFIDXCOL, AND LISTCOL ARE SET EQUAL TO                MVLXCOL[XCOLCB][YCOLCB], REFIDXLXCOL[XCOLCB][YCOLCB],                AND LX, RESPECTIVELY, AVAILABLEFLAGLXCOL IS SET TO 1.            -   OTHERWISE (PREDFLAGLXCOL[XCOLCB][YCOLCB] IS EQUAL TO 0),                THE FOLLOWING APPLIES:                -   IF DIFFPICORDERCNT(APIC, CURRPIC) IS LESS THAN OR                    EQUAL TO 0 FOR EVERY PICTURE APIC IN EVERY REFERENCE                    PICTURE LIST OF THE CURRENT SLICE AND                    PREDFLAGLYCOL[XCOLCB][YCOLCB] IS EQUAL TO 1, MVCOL,                    REFIDXCOL, AND LISTCOL ARE SET TO                    MVLYCOL[XCOLCB][YCOLCB], REFIDXLYCOL[XCOLCB][YCOLCB]                    AND LY, RESPECTIVELY, WITH Y BEING EQUAL TO !X WHERE                    X BEING THE VALUE OF X THIS PROCESS IS INVOKED FOR.                    AVAILABLEFLAGLXCOL IS SET TO 1.                -   BOTH THE COMPONENTS OF MVLXCOL ARE SET TO 0 AND                    AVAILABLEFLAGLXCOL IS SET EQUAL TO 0.        -   When availableFlagLXCol is equal to TRUE, mvLXCol and            availableFlagLXCol are derived as follows:            -   If LongTermRefPic(currPic, currCb, refIdxLX, LX) is not                equal to LongTermRefPic(ColPic, colCb, refIdxCol,                listCol), both components of mvLXCol are set equal to 0                and availableFlagLXCol is set equal to 0.            -   Otherwise, the variable availableFlagLXCol is set equal                to 1, refPicList[listCol][refIdxCol] is set to be the                picture with reference index refIdxCol in the reference                picture list listCol of the slice containing coding                block colCb in the collocated picture specified by                ColPic, and the following applies:                -   . . .

FIG. 22 is a block diagram of a video processing apparatus 2200. Theapparatus 2200 may be used to implement one or more of the methodsdescribed herein. The apparatus 2200 may be embodied in a smartphone,tablet, computer, Internet of Things (IoT) receiver, and so on. Theapparatus 2200 may include one or more processors 2202, one or morememories 2204 and video processing hardware 2206. The processor(s) 2202may be configured to implement one or more methods described in thepresent document. The memory (memories) 2204 may be used for storingdata and code used for implementing the methods and techniques describedherein. The video processing hardware 2206 may be used to implement, inhardware circuitry, some techniques described in the present document.The video processing hardware 2206 may be partially or completelyincludes within the processor(s) 2202 in the form of dedicated hardware,or graphical processor unit (GPU) or specialized signal processingblocks.

Some embodiments may be described using the following clause-baseddescription.

Some example embodiments of techniques described in item 1 of section 4include:

1. A method of video processing (e.g., method 2300 depicted in FIG. 23),comprising: applying (2302) a pruning process to a merge listconstruction of a current video block that is partitioned using atriangular partition mode (TMP) in which the current video block ispartitioned into at least two non-rectangular sub-blocks, wherein thepruning process is same as another pruning process for another videoblock that is partitioned using a non-TMP partition; and performing(2304) a conversion between the current video block and a bitstreamrepresentation of the current video block based on the merge listconstruction.

2. The method of claim 1, wherein the pruning process comprises using apartial pruning to spatial merge candidates of the current video block.

3. The method of claim 1, wherein the pruning process comprises applyingfull or partial pruning to the current video block based on a blockdimension rule that specifies to use full or partial pruning based ondimensions of the current video block.

4. The method of claim 1, wherein the pruning process comprises using adifferent order of neighboring blocks during the merge list constructionprocess.

Some example embodiments of techniques described in item 2 of section 4include:

1. A method of video processing, comprising: determining, during aconversion between a current video block and a bitstream representationof the current video block, about availability of an alternativetemporal motion vector predictor coding (ATMVP) mode for the conversionbased on list X of a neighboring block of the current video block,wherein X is an integer and a value of X depends on an encodingcondition of the current video block, and performing the conversionbased on the availability of the ATMVP mode.

2. The method of claim 1, wherein X indicates a location of a collocatedvideo picture from which a temporal motion vector prediction used forthe conversion between the current video block and the bitstreamrepresentation is performed.

3. The method of claim 1, wherein X is determined by comparing pictureorder counts (POCs) of all reference pictures in all reference lists forthe current video block with a POC of a current video picture of thecurrent video block.

4. The method of claim 3, wherein in case that the comparing shows thatthe POCs are <=the POC of the current picture, then setting X=1,otherwise, setting X=0.

5. The method of claim 1, wherein motion information stored in ahistory-based motion vector predictor table is used for initializingmotion vector in the ATMVP mode.

Some example embodiments of techniques described in item 3 of section 4include:

1. A method of video processing, comprising: determining, during aconversion between a current video block and a bitstream representationof the current video block, that a sub-block based coding technique inwhich the current video block is partitioned into at least twosub-blocks, wherein each sub-block capable of deriving its own motioninformation, is used for the conversion; and performing the conversionusing a merge list construction process for the current video block thatis aligned with a block based derivation process for collocated motionvectors.

2. The method of claim 1, wherein the merge list construction processand the derivation process comprise performing uni-prediction from listY, and wherein motion vectors of list Y are scaled to a target referencepicture list X.

3. The method of claim 1, wherein the merge list construction processand the derivation process comprise performing bi-prediction with targetreference picture list X, then motion vectors of list Y are scaled tothat of list X, where Y is determined according to a rule.

Some example embodiments of techniques described in item 4 of section 4include:

1. A method of video processing, comprising: determining, based ondimensions of a current video block of a video picture and/or anenablement of a merge sharing status in which merge candidates fromdifferent coding tools are shared, between a condition being met and thecondition being not met; and performing a conversion between the currentvideo block and a bitstream representation of the current video blockbased on the condition.

2. The method of claim 1, wherein the performing the conversioncomprises skipping deriving spatial merge candidates in case that thecondition is met.

3. The method of claim 1, wherein the performing the conversioncomprises skipping deriving history-based motion vector candidates incase that the condition is met.

4. The method of any of claims 1-3, wherein it is determined that thecondition is met based on the current video block being under a sharednode in the video picture.

Some example embodiments of techniques described in item 5 of section 4include:

1. A method of video processing, comprising: making a determination,during a conversion between a current video block and a bitstreamrepresentation of the current video block, that a coding tool isdisabled for the conversion, wherein the bitstream representation isconfigured to provide an indication that a maximum number of mergecandidates for the coding tool is zero; and performing the conversionusing the determination that the coding tool is disabled.

2. The method of claim 1, wherein the coding tool corresponds to intrablock copy in which pixels of the current video block are coded fromother pixels in a video region of the current video block.

3. The method of claim 1, wherein the coding tool is a sub-block codingtool.

4. The method of claim 3, wherein the sub-block coding tool is an affinecoding tool or an alternate motion vector predictor tool.

5. The method of any of claims 1-4, wherein the performing theconversion includes processing the bitstream by skipping syntax elementsrelated to the coding tool.

Some example embodiments of techniques described in item 6 of section 4include:

1. A method of video processing, comprising: making a determination,during a conversion between a current video block and a bitstreamrepresentation of the current video block using a rule that specifiesthat a first syntax element in the bitstream representation isconditionally present based on a second syntax element indicative of amaximum number of merge candidates used by a coding tool used during theconversion; and performing the conversion between the current videoblock and a bitstream representation of the current video block based onthe determination.

2. The method of claim 1, wherein the first syntax element correspondsto a merge flag.

3. The method of claim 1, wherein the first syntax element correspondsto a skip flag.

4. The method of any of claims 1-3, wherein the coding tool is asub-band coding tool and the second syntax element corresponds to amaximum allowed merge candidates for the sub-band coding tool.

34. The method of any of clauses 1 to 33, wherein the conversionincludes generating the bitstream representation from the current videoblock.

35. The method of any of clauses 1 to 33, wherein the conversionincludes generating samples of the current video block from thebitstream representation.

36. A video processing apparatus comprising a processor configured toimplement a method recited in any one or more of clauses 1 to 35.

37. A computer readable medium having code stored thereon, the code,upon execution, causing a processor to implement a method recited in anyone or more of clauses 1 to 35.

FIG. 24 is a block diagram showing an example video processing system2400 in which various techniques disclosed herein may be implemented.Various implementations may include some or all of the components of thesystem 2400. The system 2400 may include input 2402 for receiving videocontent. The video content may be received in a raw or uncompressedformat, e.g., 8 or 10 bit multi-component pixel values, or may be in acompressed or encoded format. The input 2402 may represent a networkinterface, a peripheral bus interface, or a storage interface. Examplesof network interface include wired interfaces such as Ethernet, passiveoptical network (PON), etc. and wireless interfaces such as Wi-Fi orcellular interfaces.

The system 2400 may include a coding component 2404 that may implementthe various coding or encoding methods described in the presentdocument. The coding component 2404 may reduce the average bitrate ofvideo from the input 2402 to the output of the coding component 2404 toproduce a coded representation of the video. The coding techniques aretherefore sometimes called video compression or video transcodingtechniques. The output of the coding component 2404 may be eitherstored, or transmitted via a communication connected, as represented bythe component 2406. The stored or communicated bitstream (or coded)representation of the video received at the input 2402 may be used bythe component 2408 for generating pixel values or displayable video thatis sent to a display interface 2410. The process of generatinguser-viewable video from the bitstream representation is sometimescalled video decompression. Furthermore, while certain video processingoperations are referred to as “coding” operations or tools, it will beappreciated that the coding tools or operations are used at an encoderand corresponding decoding tools or operations that reverse the resultsof the coding will be performed by a decoder.

Examples of a peripheral bus interface or a display interface mayinclude universal serial bus (USB) or high definition multimediainterface (HDMI) or Displayport, and so on. Examples of storageinterfaces include SATA (serial advanced technology attachment), PCI,IDE interface, and the like. The techniques described in the presentdocument may be embodied in various electronic devices such as mobilephones, laptops, smartphones or other devices that are capable ofperforming digital data processing and/or video display.

FIG. 25 is a flowchart for an example for a visual media processingmethod. Steps of this flowchart are discussed in connection withembodiment 1 in Section 4 of this document. At step 2502, the processdetermines that a first video block of a visual media data uses ageometric partitioning mode (GPM) and a second video block of the visualmedia data uses a non-GPM mode. At step 2504, the process constructs,based on a unified pruning process, a first merge list for the firstvideo block and a second merge list for the second video block, whereinthe first merge list and the second merge list comprise mergecandidates, and the pruning process includes adding anew merge candidateto the merge list based on comparing motion information of the new mergecandidate with motion information of at least one merge candidate in themerge list, wherein the GPM comprises splitting the first video blockinto multiple prediction partitions to apply motion predictionseparately, and at least one partition having a non-rectangular shape.

FIG. 26 is a flowchart for an example for a visual media processingmethod. Steps of this flowchart are discussed in connection withembodiment 2 in Section 4 of this document. At step 2602, the processdetermines, for a conversion between a current video block of visualmedia data and a bitstream representation of the visual media data,initial values of motion information applicable to the current videoblock based on a rule, wherein the rule specifies checking whether asub-block based temporal motion vector predictor coding (SbTMVP) mode isavailable for the current video block based on a reference list (denotedlist X) of a neighboring block of the current video block, where X is aninteger and a value of X depends at least on an encoding condition ofthe neighboring block. At step 2604, the process performs the conversionbased on the determining.

FIG. 27 is a flowchart for an example for a visual media processingmethod. Steps of this flowchart are discussed in connection withembodiment 3 in Section 4 of this document. At step 2702, the processderiving, for a conversion between a current video block of a visualmedia data and a bitstream representation of the visual media data, oneor more collocated motion vectors for one or more sub-blocks of thecurrent video block based on a rule, wherein the rule specifies to use aunified derivation process for deriving the one or more collocatedmotion vectors irrespective of a coding tool used for coding the currentvideo block into the bitstream representation. At step 2704, the processperforms the conversion using the merge list comprising the one or morecollocated motion vectors.

FIG. 28 is a flowchart for an example for a visual media processingmethod. Steps of this flowchart are discussed in connection withembodiment 4 in Section 4 of this document. At step 2802, the processidentifies one or more conditions associated with dimensions of acurrent video block of visual media data, wherein an intra block copy(IBC) mode is applied to the current video block. At step 2804, theprocess determines, based on whether the one or more conditionsassociated with the dimensions of the current video block are met, amotion candidate list construction process of a motion candidate listfor the current video block. At step 2806, the process performs aconversion between the current video block and a bitstreamrepresentation of the current video block based on the motion candidatelist.

FIG. 29 is a flowchart for an example for a visual media processingmethod. Steps of this flowchart are discussed in connection withembodiment 5 in Section 4 of this document. At step 2902, the processmakes a determination, for a conversion between a current video block ofa visual media data and a bitstream representation of the visual mediadata, that a coding technique is disabled for the conversion, whereinthe bitstream representation is configured to include a field indicatingthat a maximum number of merge candidates for the coding technique iszero. At step 2904, the process performs the conversion based on thedetermination that the coding technique is disabled.

FIG. 30 is a flowchart for an example for a visual media processingmethod. Steps of this flowchart are discussed in connection withembodiment 6 in Section 6 of this document. At step 3002, the processmakes a determination, for a conversion between a current video blockand a bitstream representation of the current video block using a rulespecifying that a first syntax element in the bitstream representationis conditionally included based on a second syntax element in thebitstream representation indicative of a maximum number of mergecandidates associated with at least one coding technique applied to thecurrent video block. At step 3004, the process performs the conversionbetween the current video block and a bitstream representation of thecurrent video block based on the determination.

FIG. 31 is a flowchart for an example for a visual media processingmethod. Steps of this flowchart are discussed in connection withembodiment 4 in Section 4 of this document. At step 3102, the processconstructs, for a conversion between a current video block of a videoand a bitstream representation of the video, a motion candidate listusing a motion list construction process that is based on one or moreconditions associated with dimensions of the current video block. Atstep 3104, the process performs the conversion using the motioncandidate list, wherein the motion candidate list includes zero or moreintra block copy mode candidates and/or zero or more advanced motionvector predictor candidates.

Some embodiments of the present document are now presented inclause-based format.

A1. A visual media processing method, comprising:

determining that a first video block of a visual media data uses ageometric partitioning mode (GPM) and a second video block of the visualmedia data uses a non-GPM mode;

constructing, based on a pruning process, a first merge list for thefirst video block and a second merge list for the second video block,wherein the first merge list and the second merge list comprise mergecandidates, and the pruning process includes adding anew merge candidateto the merge list based on comparing motion information of the new mergecandidate with motion information of at least one merge candidate in themerge list, wherein the GPM comprises splitting the first video blockinto multiple prediction partitions to apply motion predictionseparately, and at least one partition having a non-rectangular shape.

Accordingly, the pruning process is a unified pruning process that issimilarly applied to different video blocks, regardless of whether thevideo blocks are processed using a GPM or another conventionalpartitioning mode.

For example, the clause A1 may alternatively be implemented as a methodcomprising constructing, for a conversion between a current video blockof a visual media data and a bitstream representation of the visualmedia data, a merge list comprising motion candidates based on a rule ofconstruction. The method may further include performing the conversionusing the merge list. The rule of construction may use a unifiedconstruction procedure for constructing the merge candidate list. Theunified construction procedure may, for example, apply a pruning processin a unified manner such that the merge list for the current videoblock, split with GPM may be constructed using the same constructionprocedure as a second video block that is not split with GPM procedure,including, for example, using a same pruning process for generating boththe first and the second merge lists for the first and the second videoblocks respectively.

A2. The method of clause A1, wherein the merge candidates in the mergelist are spatial merge candidates, and wherein the unified pruningprocess is a partial pruning process.

A3. The method of any one or more of clauses A1-A2, wherein the firstmerge list or the second merge list constructed based on the unifiedpruning process includes a maximum of four spatial merge candidates fromneighboring video blocks of the first video block and/or the secondvideo block.

A4. The method of any one or more of clauses A1-A3, wherein theneighboring video blocks of the first video block and/or the secondvideo block include: one video block (denoted B2) in a top left corner,two video blocks (denoted B1 and B0) in a top right corner sharing acommon edge, and two video blocks (denoted A1 and A0) in a bottom leftcorner sharing a common edge.

A5. The method of clause A4, wherein comparing the motion information ofthe new merge candidate with the motion information of the at least onemerge candidate in the merge list is associated with performingpair-wise comparisons in an ordered sequence including: a comparisonbetween B1 and A1, a comparison between B1 and B0, a comparison betweenA0 and A1, a comparison between B2 and A1, and a comparison between B2and B1, and further wherein comparing the motion information is same forthe first video block and the second video block.

A6. The method of clause A1, wherein the unified pruning process is afull pruning process that is selectively applied to the spatial mergecandidates, based on the first video block or the second video blocksatisfying one or more threshold conditions.

A7. The method of clause A6, wherein the one or more thresholdconditions are related to dimensions of the first video block and/ordimensions of the second video block and/or a number of samples in thefirst video block and/or a number of samples in the second video block.

A8. The method of any one or more of clauses A4-A7, wherein a comparisoninvolving B2 is selectively performed based on a number of availablemerge candidates in the first merge list or the second merge list.

A9. The method of any one or more of clauses A4-A7, wherein theneighboring video blocks are partitioned using a non-GPM mode, andwherein a comparison involving B2 is always performed based on a numberof available merge candidates in the first merge list or the secondmerge list.

B1. A method for visual media processing, comprising:

determining, for a conversion between a current video block of visualmedia data and a bitstream representation of the visual media data,initial values of motion information applicable to the current videoblock based on a rule, wherein the rule specifies checking whether asub-block based temporal motion vector predictor coding (SbTMVP) mode isavailable for the current video block based on a reference list (denotedlist X) of a neighboring block of the current video block, where X is aninteger and a value of X depends at least on an encoding condition ofthe neighboring block; and

performing the conversion based on the determining.

B2. The method of clause B1, wherein X indicates a location of acollocated video picture from which a temporal motion vector predictionused for the conversion between the current video block and thebitstream representation is performed.

B3. The method of clause B1, wherein X is determined by comparingpicture order counts (POCs) of all reference pictures in all referencelists for the current video block with a POC of a current video pictureof the current video block.

B4. The method of clause B3, wherein in case that results of thecomparing indicates that the POCs of all reference pictures in allreference lists for the current video block are less than or equal tothe POC of the current picture of the current video picture, settingX=1, otherwise, setting X=0.

B5. The method of clause B2, wherein in case that a reference pictureassociated with list X of the neighboring block is available and POC ofthe reference picture is same as POC of the collocated video picture,further comprising:

setting the initial values of motion information in the SbTMVP mode tomotion information associated with list X of the neighboring block ofthe current video block.

B6. The method of clause B1, wherein motion information stored in ahistory-based motion vector predictor table is used for setting theinitial values of motion information in the SbTMVP mode.

B7. The method of clause B6, wherein the motion information stored inthe history-based motion vector predictor table is a first-availablemotion information in the history-based motion vector predictor table.

B8. The method of clause B7, wherein the first-available motioninformation is associated with a reference picture.

B9. The method of clause B8, wherein the reference picture is acollocated picture.

B10. The method of clause B1, wherein X is predefined value.

B11. The method of clause B10, wherein X is 0 or 1.

C1. A visual media processing method, comprising:

deriving, for a conversion between a current video block of a visualmedia data and a bitstream representation of the visual media data, oneor more collocated motion vectors for one or more sub-blocks of thecurrent video block based on a rule, wherein the rule specifies to use aunified derivation process for deriving the one or more collocatedmotion vectors irrespective of a coding tool used for coding the currentvideo block into the bitstream representation; and

performing the conversion using the merge list comprising the one ormore collocated motion vectors.

C2. The method of clause C1, wherein in a case that the derivationprocess utilizes uni-prediction from a reference picture list denotedlist Y, motion vectors of the list Y are scaled to a target referencepicture list denoted list X, where X, Y are integers and a value of Xdepends at least on the coding tool used for the current video block.

C3. The method of clause C1, wherein in a case that the derivationprocess utilizes bi-prediction from a target reference picture listdenoted list Y, the rule further specifies scaling motion vectors of thelist Y to a target reference picture list denoted list X, where X, Y areintegers and a value of X depends at least on the coding tool used forthe current video block.

C4. The method of any one or more of clauses C2-C3, wherein the rulefurther specifies determining X by comparing picture order counts (POCs)of all reference pictures in all reference lists for the current videoblock with a POC of a current video picture of the current video block.

C5. The method of clause C4, wherein the rule further specifiesdetermining Y by comparing POCs of all reference pictures in allreference lists for the current video block with the POC of the currentpicture of the current video block.

C6. The method of clause C5, wherein in a case that results of thecomparing indicate that POCs of all the reference pictures in all thereference lists for the current video block are less than or equal tothe POC of the current picture of the current video picture, the rulespecifies setting Y=X, otherwise, the rule specifies setting X to alocation of a collocated video picture from which a temporal motionvector prediction used for the conversion between the current videoblock and the bitstream representation is performed.

D1. A method for visual media processing, comprising:

identifying one or more conditions associated with dimensions of acurrent video block of visual media data, wherein an intra block copy(IBC) mode is applied to the current video block;

determining, based on whether the one or more conditions associated withthe dimensions of the current video block are met, a motion candidatelist construction process of a motion candidate list for the currentvideo block, and

performing a conversion between the current video block and a bitstreamrepresentation of the current video block based on the motion candidatelist.

D2. A method for visual media processing, comprising:

constructing, for a conversion between a current video block of a videoand a bitstream representation of the video, a motion candidate listusing a motion list construction process that is based on one or moreconditions associated with dimensions of the current video block; and

performing the conversion using the motion candidate list, wherein themotion candidate list includes zero or more intra block copy modecandidates and/or zero or more advanced motion vector predictorcandidates.

D3. The method of any one or more of clauses D1-D2, wherein the motioncandidate list construction process comprises skipping derivation ofspatial merge candidates in case that the one or more conditions aremet.

D4. The method of any one or more of clauses D1-D2, wherein the motioncandidate list construction process comprises skipping derivation ofhistory-based motion vector candidates in case that the one or moreconditions are met.

D5. The method of any one or more of clauses D1-D2, wherein the motioncandidate list construction process comprises skipping derivation ofpairwise merge candidates in case that the one or more conditions aremet.

D6. The method of any one or more of clauses D1-D2, wherein the motioncandidate list construction process comprises reducing a total number ofmaximum pruning operations in case that the one or more conditions aremet.

D7. The method of clause D5, wherein the total number of maximum pruningoperations is reduced to zero.

D8. The method of any one or more clauses D1-D7, wherein the one or moreconditions are met in case that a product of a width of the currentvideo block and a height of the current video block is less than orequal to a threshold value.

D9. The method of clause D8, wherein the threshold value is 64, 32, or16.

D10. The method of any one or more clauses D1-D9, wherein the one ormore conditions are met in case that a width of the current video blockand/or a height of the current video block is less than a thresholdvalue.

D11. The method of clause D10, wherein the threshold value is 4 or 8.

D12. The method of any one or more of clauses D1-D2, wherein the motioncandidate list includes an IBC merge list or an IBC motion vectorprediction list.

E1. A method for visual media processing, comprising:

making a determination, for a conversion between a current video blockof a visual media data and a bitstream representation of the visualmedia data, that a coding technique is disabled for the conversion,wherein the bitstream representation is configured to include a fieldindicating that a maximum number of merge candidates for the codingtechnique is zero; and

performing the conversion based on the determination that the codingtechnique is disabled.

E2. The method of clause E1, wherein the bitstream representation isfurther configured to skip signalling of one or more syntax elementsbased on the field indicating that the maximum number of mergecandidates for the coding technique is zero.

E3. The method of clause E1, wherein the coding technique corresponds tointra block copy in which samples of the current video block are codedfrom other samples in a video region of the current video block.

E4. The method of clause E1, wherein the coding technique is a sub-blockcoding technique.

E5. The method of clause E4, wherein the sub-block coding technique isan affine coding technique or an alternate motion vector predictortechnique.

E6. The method of any one or more of clauses E1-E2, wherein the codingtechnique applied includes one of: combined intra inter prediction(CIIP), geometry partition mode (GPM), decoder motion vector refinement(DMVR), sub-block merge, intra block copy merge, regular merge, or mergewith motion vector difference (MMVD).

F1. A method for visual media processing, comprising:

making a determination, for a conversion between a current video blockand a bitstream representation of the current video block using a rulespecifying that a first syntax element in the bitstream representationis conditionally included based on a second syntax element in thebitstream representation indicative of a maximum number of mergecandidates associated with at least one coding technique applied to thecurrent video block; and

performing the conversion between the current video block and abitstream representation of the current video block based on thedetermination.

F2. The method of clause F1, wherein the first syntax elementcorresponds to a merge flag.

F3. The method of clause F1, wherein the first syntax elementcorresponds to a skip flag.

F4. The method of any one or more of clauses F1-F3, wherein the maximumnumber of merge candidates is zero.

F5. The method of clause F4, wherein the second syntax element isskipped from inclusion in the bitstream representation, furthercomprising:

inferring that the second syntax element is zero.

F6. The method of any one or more of clauses F1-F5, wherein the at leastone coding technique includes combined intra inter prediction (CIIP),geometry partition mode (GPM), decoder motion vector refinement (DMVR),sub-block merge, intra block copy merge, regular merge, or merge withmotion vector difference (MMVD).

F7. The method of any one or more of clauses F1-F6, wherein the rulefurther specifies identifying that the first syntax element correspondsto a Boolean true and the at least one coding technique is enabled.

F8. The method of clause F7, wherein the rule further specifiesdisabling intra block copy (IBC) technique for a slice, a tile, a brick,a picture or the current video block.

F9. The method of clause F7, wherein the rule further specifiesdisabling merge with motion vector difference (MMVD) technique for aslice, a tile, a brick, a picture or the current video block.

F10. The method of clause F7, wherein the rule further specifiesdisabling combined intra inter prediction (CIIP) technique for a slice,a tile, a brick, a picture or the current video block.

F11. The method of clause F7, wherein the rule further specifiesdisabling geometry prediction mode (GPM) technique for a slice, a tile,a brick, a picture or the current video block.

G1. The method of any of clauses A1 to F11, wherein the conversionincludes generating the bitstream representation from the current videoblock.

G2. The method of any of clauses A1 to F11, wherein the conversionincludes generating samples of the current video block from thebitstream representation.

G3. A video processing apparatus comprising a processor configured toimplement a method recited in any one or more of clauses A1 to F11.

G4. A video encoding apparatus comprising a processor configured toimplement a method recited in any one or more of clauses A1 to F11.

G5. A video decoding apparatus comprising a processor configured toimplement a method recited in any one or more of clauses A1 to F11.

G6. A computer readable medium having code stored thereon, the code,upon execution, causing a processor to implement a method recited in anyone or more of clauses A1 to F11.

In the present document, the term “video processing” or “visual mediaprocessing” may refer to video encoding, video decoding, videocompression or video decompression. For example, video compressionalgorithms may be applied during conversion from pixel representation ofa video to a corresponding bitstream representation or vice versa. Thebitstream representation of a current video block may, for example,correspond to bits that are either co-located or spread in differentplaces within the bitstream, as is defined by the syntax. For example, amacroblock may be encoded in terms of transformed and coded errorresidual values and also using bits in headers and other fields in thebitstream. Furthermore, during conversion, a decoder may parse abitstream with the knowledge that some fields may be present, or absent,based on the determination, as is described in the above solutions.Similarly, an encoder may determine that certain syntax fields are orare not to be included and generate the coded representation accordinglyby including or excluding the syntax fields from the codedrepresentation.

The disclosed and other solutions, examples, embodiments, modules andthe functional operations described in this document can be implementedin digital electronic circuitry, or in computer software, firmware, orhardware, including the structures disclosed in this document and theirstructural equivalents, or in combinations of one or more of them. Thedisclosed and other embodiments can be implemented as one or morecomputer program products, i.e., one or more modules of computer programinstructions encoded on a computer readable medium for execution by, orto control the operation of, data processing apparatus. The computerreadable medium can be a machine-readable storage device, amachine-readable storage substrate, a memory device, a composition ofmatter effecting a machine-readable propagated signal, or a combinationof one or more them. The term “data processing apparatus” encompassesall apparatus, devices, and machines for processing data, including byway of example a programmable processor, a computer, or multipleprocessors or computers. The apparatus can include, in addition tohardware, code that creates an execution environment for the computerprogram in question, e.g., code that constitutes processor firmware, aprotocol stack, a database management system, an operating system, or acombination of one or more of them. A propagated signal is anartificially generated signal, e.g., a machine-generated electrical,optical, or electromagnetic signal, that is generated to encodeinformation for transmission to suitable receiver apparatus.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, and it can bedeployed in any form, including as a stand-alone program or as a module,component, subroutine, or other unit suitable for use in a computingenvironment. A computer program does not necessarily correspond to afile in a file system. A program can be stored in a portion of a filethat holds other programs or data (e.g., one or more scripts stored in amarkup language document), in a single file dedicated to the program inquestion, or in multiple coordinated files (e.g., files that store oneor more modules, sub programs, or portions of code). A computer programcan be deployed to be executed on one computer or on multiple computersthat are located at one site or distributed across multiple sites andinterconnected by a communication network.

The processes and logic flows described in this document can beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application specific integrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read only memory ora random-access memory or both. The essential elements of a computer area processor for performing instructions and one or more memory devicesfor storing instructions and data. Generally, a computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto optical disks, or optical disks. However, a computerneed not have such devices. Computer readable media suitable for storingcomputer program instructions and data include all forms of non-volatilememory, media and memory devices, including by way of examplesemiconductor memory devices, e.g., EPROM, EEPROM, and flash memorydevices; magnetic disks, e.g., internal hard disks or removable disks;magneto optical disks; and CD ROM and DVD-ROM disks. The processor andthe memory can be supplemented by, or incorporated in, special purposelogic circuitry.

While this patent document contains many specifics, these should not beconstrued as limitations on the scope of any subject matter or of whatmay be claimed, but rather as descriptions of features that may bespecific to particular embodiments of particular techniques. Certainfeatures that are described in this patent document in the context ofseparate embodiments can also be implemented in combination in a singleembodiment. Conversely, various features that are described in thecontext of a single embodiment can also be implemented in multipleembodiments separately or in any suitable subcombination. Moreover,although features may be described above as acting in certaincombinations and even initially claimed as such, one or more featuresfrom a claimed combination can in some cases be excised from thecombination, and the claimed combination may be directed to asubcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. Moreover, the separation of various system components in theembodiments described in this patent document should not be understoodas requiring such separation in all embodiments.

Only a few implementations and examples are described and otherimplementations, enhancements and variations can be made based on whatis described and illustrated in this patent document.

We claim:
 1. A method of processing video data, comprising: determining,during a conversion between a current block of a video and a bitstreamof the video, that the current block is coded with a geometricpartitioning mode which is a prediction mode; constructing a candidatelist for the current block, wherein the constructing includes checkingan availability of a spatial motion vector candidate at a specificneighboring block B2 based on a number of available candidates in thecandidate list, wherein the specific neighboring block B2 is at a topleft corner of the current block, wherein the candidate list comprisesat least one spatial motion vector candidate; determining, based on thecandidate list, a first motion information for a first geometricpartition of the current block and a second motion information for asecond geometric partition of the current block; applying a weightingprocess for generating a final prediction for samples of the currentblock based on a weighted sum of prediction samples derived based on thefirst motion information and the second motion information; andperforming the conversion based on the applying.
 2. The method of claim1, wherein when the number of available candidates in the candidate listis 4, the spatial motion vector candidate at the specific neighboringblock B2 is unavailable.
 3. The method of claim 1, wherein the candidatelist is constructed based on a pruning process, wherein the pruningprocess comprises comparing motion information between at least twospatial motion vector candidates to avoid identical spatial motionvector candidates.
 4. The method of claim 3, wherein the constructing,based on the pruning process, the candidate list for the current blockincludes checking an availability of a spatial motion vector candidateat a specific neighboring block A1, wherein the specific neighboringblock A1 is adjacent to a lower left corner to the current block, thechecking comprising: when the candidate list includes a spatial motionvector candidate at a specific neighboring block B1, wherein thespecific neighboring block B1 is adjacent to a top right corner to thecurrent block, comparing motion information between the spatial motionvector candidates at the specific neighboring block A1 and the specificneighboring block B1, and determining that the spatial motion vectorcandidate at the specific neighboring block A1 is unavailable, based onthe comparing result indicates that the motion information of thespatial motion vector candidate at A1 is identical to that at B1.
 5. Themethod of claim 3, wherein the constructing, based on the pruningprocess, the candidate list for the current block includes checking anavailability of a spatial motion vector candidate at a specificneighboring block B0, wherein the specific neighboring block B0 is at atop right corner of the current block, the checking comprising: when thecandidate list includes a spatial motion vector candidate at a specificneighboring block B1, wherein the specific neighboring block B1 isadjacent to a top right corner to the current block, comparing motioninformation between the spatial motion vector candidates at the specificneighboring block B0 and the specific neighboring block B1; anddetermining that the spatial motion vector candidate at the specificneighboring block B0 is unavailable, based on the comparing resultindicates that the motion information of the spatial motion vectorcandidate at B0 is identical to that at B1.
 6. The method of claim 3,wherein the constructing, based on the pruning process, the candidatelist for the current block includes checking an availability of aspatial motion vector candidate at a specific neighboring block A0,wherein the specific neighboring block A0 is at a lower left corner ofthe current block, the checking comprising: when the candidate listincludes a spatial motion vector candidate at a specific neighboringblock A1, wherein the specific neighboring block A1 is adjacent to alower left corner to the current block, comparing motion informationbetween the spatial motion vector candidates at a specific neighboringblock A0 and the specific neighboring block A1; and determining that thespatial motion vector candidate at the specific neighboring block A0 isunavailable, based on the comparing result indicates that the motioninformation of the spatial motion vector candidate at A0 is identical tothat at A1.
 7. The method of claim 3, wherein checking the availabilityof the spatial motion vector candidate at the specific neighboring blockB2 further includes: when the candidate list includes spatial motionvector candidates at specific neighboring blocks A1 and B1, wherein thespecific neighboring block B1 is adjacent to a top right corner to thecurrent block and the specific neighboring block A1 is adjacent to alower left corner to the current block, comparing motion informationbetween the spatial motion vector candidates at the specific neighboringblock B2 and the specific neighboring blocks A1 and B1, and determiningthat the spatial motion vector candidate at the specific neighboringblock B2 is unavailable, based on the comparing result indicates thatthe motion information of the spatial motion vector candidate at B2 isidentical to that at A1 or B1.
 8. The method of claim 1, furthercomprising: storing, in response to the first motion information beingfrom a first reference picture list LX and the second motion informationbeing from a second reference picture list L(1−X), a second single setof motion information for a m×n subblock within a weighted area of thecurrent block, wherein the second single set of motion informationcomprises bi-prediction motion information, wherein X=0 or X=1.
 9. Themethod of claim 1, further comprising: storing a third single set ofmotion information for a m×n subblock within a non-weighted area of thecurrent block, wherein the third single set of motion informationcomprises uni-prediction motion information which is based on the firstmotion information or the second motion information.
 10. The method ofclaim 1, wherein a spatial motion vector candidate corresponding to aneighboring block which is coded with an intra block copy mode isexcluded from the candidate list for the current block, wherein in theintra block copy mode, prediction samples of the neighboring block arederived from blocks of sample values of the same decoded video region asdetermined by block vectors.
 11. The method of claim 1, wherein theconversion includes encoding the current block into the bitstream. 12.The method of claim 1, wherein the conversion includes decoding thecurrent block from the bitstream.
 13. An apparatus for processing videodata comprising a processor and a non-transitory memory withinstructions thereon, wherein the instructions upon execution by theprocessor, cause the processor to: determine, during a conversionbetween a current block of a video and a bitstream of the video, thatthe current block is coded with a geometric partitioning mode which is aprediction mode; construct a candidate list for the current block,wherein the constructing includes checking an availability of a spatialmotion vector candidate at a specific neighboring block B2 based on anumber of available candidates in the candidate list, wherein thespecific neighboring block B2 is at a top left corner of the currentblock, wherein the candidate list comprises at least one spatial motionvector candidate; determine, based on the candidate list, a first motioninformation for a first geometric partition of the current block and asecond motion information for a second geometric partition of thecurrent block; apply a weighting process for generating a finalprediction for samples of the current block based on a weighted sum ofprediction samples derived based on the first motion information and thesecond motion information; and perform the conversion based on theweighting process.
 14. The apparatus of claim 13, wherein when thenumber of available candidates in the candidate list is 4, the spatialmotion vector candidate at the specific neighboring block B2 isunavailable; wherein the candidate list is constructed based on apruning process, wherein the pruning process comprises comparing motioninformation between at least two spatial motion vector candidates toavoid identical spatial motion vector candidates; wherein theconstructing, based on the pruning process, the candidate list for thecurrent block includes checking an availability of a spatial motionvector candidate at a specific neighboring block A1, wherein thespecific neighboring block A1 is adjacent to a lower left corner to thecurrent block, the checking comprising: when the candidate list includesa spatial motion vector candidate at a specific neighboring block B1,wherein the specific neighboring block B1 is adjacent to a top rightcorner to the current block, comparing motion information between thespatial motion vector candidates at the specific neighboring block A1and the specific neighboring block B1, and determining that the spatialmotion vector candidate at the specific neighboring block A1 isunavailable, based on the comparing result indicates that the motioninformation of the spatial motion vector candidate at A1 is identical tothat at B1; wherein the constructing, based on the pruning process, thecandidate list for the current block includes checking an availabilityof a spatial motion vector candidate at a specific neighboring block B0,wherein the specific neighboring block B0 is at a top right corner ofthe current block, the checking comprising: when the candidate listincludes a spatial motion vector candidate at a specific neighboringblock B1, wherein the specific neighboring block B1 is adjacent to a topright corner to the current block, comparing motion information betweenthe spatial motion vector candidates at the specific neighboring blockB0 and the specific neighboring block B1; and determining that thespatial motion vector candidate at the specific neighboring block B0 isunavailable, based on the comparing result indicates that the motioninformation of the spatial motion vector candidate at B0 is identical tothat at B1; wherein the constructing, based on the pruning process, thecandidate list for the current block includes checking an availabilityof a spatial motion vector candidate at a specific neighboring block A0,wherein the specific neighboring block A0 is at a lower left corner ofthe current block, the checking comprising: when the candidate listincludes a spatial motion vector candidate at a specific neighboringblock A1, wherein the specific neighboring block A1 is adjacent to alower left corner to the current block, comparing motion informationbetween the spatial motion vector candidates at a specific neighboringblock A0 and the specific neighboring block A1; and determining that thespatial motion vector candidate at the specific neighboring block A0 isunavailable, based on the comparing result indicates that the motioninformation of the spatial motion vector candidate at A0 is identical tothat at A1; wherein checking the availability of the spatial motionvector candidate at the specific neighboring block B2 further includes:when the candidate list includes spatial motion vector candidates atspecific neighboring blocks A1 and B1, wherein the specific neighboringblock B1 is adjacent to a top right corner to the current block and thespecific neighboring block A1 is adjacent to a lower left corner to thecurrent block, comparing motion information between the spatial motionvector candidates at the specific neighboring block B2 and the specificneighboring blocks A1 and B1, and determining that the spatial motionvector candidate at the specific neighboring block B2 is unavailable,based on the comparing result indicates that the motion information ofthe spatial motion vector candidate at B2 is identical to that at A1 orB1.
 15. The apparatus of claim 13, wherein the instructions furthercause the processor to: store, in response to the first motioninformation being from a first reference picture list LX and the secondmotion information being from a second reference picture list L(1−X), asecond single set of motion information for a m×n subblock within aweighted area of the current block, wherein the second single set ofmotion information comprises bi-prediction motion information, whereinX=0 or X=1; and store a third single set of motion information for a m×nsubblock within a non-weighted area of the current block, wherein thethird single set of motion information comprises uni-prediction motioninformation which is based on the first motion information or the secondmotion information, wherein a spatial motion vector candidatecorresponding to a neighboring block which is coded with an intra blockcopy mode is excluded from the candidate list for the current block,wherein in the intra block copy mode, prediction samples of theneighboring block are derived from blocks of sample values of the samedecoded video region as determined by block vectors.
 16. Anon-transitory computer-readable storage medium storing instructionsthat cause a processor to: determine, during a conversion between acurrent block of a video and a bitstream of the video, that the currentblock is coded with a geometric partitioning mode which is a predictionmode; construct a candidate list for the current block, wherein theconstructing includes checking an availability of a spatial motionvector candidate at a specific neighboring block B2 based on a number ofavailable candidates in the candidate list, wherein the specificneighboring block B2 is at a top left corner of the current block,wherein the candidate list comprises at least one spatial motion vectorcandidate; determine, based on the candidate list, a first motioninformation for a first geometric partition of the current block and asecond motion information for a second geometric partition of thecurrent block; apply a weighting process for generating a finalprediction for samples of the current block based on a weighted sum ofprediction samples derived based on the first motion information and thesecond motion information; and perform the conversion based on theweighting process.
 17. The non-transitory computer-readable storagemedium of claim 16, wherein when the number of available candidates inthe candidate list is 4, the spatial motion vector candidate at thespecific neighboring block B2 is unavailable; wherein the candidate listis constructed based on a pruning process, wherein the pruning processcomprises comparing motion information between at least two spatialmotion vector candidates to avoid identical spatial motion vectorcandidates; wherein the constructing, based on the pruning process, thecandidate list for the current block includes checking an availabilityof a spatial motion vector candidate at a specific neighboring block A1,wherein the specific neighboring block A1 is adjacent to a lower leftcorner to the current block, the checking comprising: when the candidatelist includes a spatial motion vector candidate at a specificneighboring block B1, wherein the specific neighboring block B1 isadjacent to a top right corner to the current block, comparing motioninformation between the spatial motion vector candidates at the specificneighboring block A1 and the specific neighboring block B1, anddetermining that the spatial motion vector candidate at the specificneighboring block A1 is unavailable, based on the comparing resultindicates that the motion information of the spatial motion vectorcandidate at A1 is identical to that at B1; wherein the constructing,based on the pruning process, the candidate list for the current blockincludes checking an availability of a spatial motion vector candidateat a specific neighboring block B0, wherein the specific neighboringblock B0 is at a top right corner of the current block, the checkingcomprising: when the candidate list includes a spatial motion vectorcandidate at a specific neighboring block B1, wherein the specificneighboring block B1 is adjacent to a top right corner to the currentblock, comparing motion information between the spatial motion vectorcandidates at the specific neighboring block B0 and the specificneighboring block B1; and determining that the spatial motion vectorcandidate at the specific neighboring block B0 is unavailable, based onthe comparing result indicates that the motion information of thespatial motion vector candidate at B0 is identical to that at B1;wherein the constructing, based on the pruning process, the candidatelist for the current block includes checking an availability of aspatial motion vector candidate at a specific neighboring block A0,wherein the specific neighboring block A0 is at a lower left corner ofthe current block, the checking comprising: when the candidate listincludes a spatial motion vector candidate at a specific neighboringblock A1, wherein the specific neighboring block A1 is adjacent to alower left corner to the current block, comparing motion informationbetween the spatial motion vector candidates at a specific neighboringblock A0 and the specific neighboring block A1; and determining that thespatial motion vector candidate at the specific neighboring block A0 isunavailable, based on the comparing result indicates that the motioninformation of the spatial motion vector candidate at A0 is identical tothat at A1; wherein checking the availability of the spatial motionvector candidate at the specific neighboring block B2 further includes:when the candidate list includes spatial motion vector candidates atspecific neighboring blocks A1 and B1, wherein the specific neighboringblock B1 is adjacent to a top right corner to the current block and thespecific neighboring block A1 is adjacent to a lower left corner to thecurrent block, comparing motion information between the spatial motionvector candidates at the specific neighboring block B2 and the specificneighboring blocks A1 and B1, and determining that the spatial motionvector candidate at the specific neighboring block B2 is unavailable,based on the comparing result indicates that the motion information ofthe spatial motion vector candidate at B2 is identical to that at A1 orB1.
 18. The non-transitory computer-readable storage medium of claim 16,wherein the instructions further cause the processor to: store, inresponse to the first motion information being from a first referencepicture list LX and the second motion information being from a secondreference picture list L(1−X), a second single set of motion informationfor a m×n subblock within a weighted area of the current block, whereinthe second single set of motion information comprises bi-predictionmotion information, wherein X=0 or X=1; and store a third single set ofmotion information for a m×n subblock within a non-weighted area of thecurrent block, wherein the third single set of motion informationcomprises uni-prediction motion information which is based on the firstmotion information or the second motion information, wherein a spatialmotion vector candidate corresponding to a neighboring block which iscoded with an intra block copy mode is excluded from the candidate listfor the current block, wherein in the intra block copy mode, predictionsamples of the neighboring block are derived from blocks of samplevalues of the same decoded video region as determined by block vectors.19. A non-transitory computer-readable recording medium storing abitstream of a video which is generated by a method performed by a videoprocessing apparatus, wherein the method comprises: determining, for acurrent block of a video, that the current block is coded with ageometric partitioning mode which is a prediction mode; constructing acandidate list for the current block, wherein the constructing includeschecking an availability of a spatial motion vector candidate at aspecific neighboring block B2 based on a number of available candidatesin the candidate list, wherein the specific neighboring block B2 is at atop left corner of the current block, wherein the candidate listcomprises at least one spatial motion vector candidate; determining,based on the candidate list, a first motion information for a firstgeometric partition of the current block and a second motion informationfor a second geometric partition of the current block; applying aweighting process for generating a final prediction for samples of thecurrent block based on a weighted sum of prediction samples derivedbased on the first motion information and the second motion information;and generating the bitstream based on the applying.
 20. Thenon-transitory computer-readable storage medium of claim 19, whereinwhen the number of available candidates in the candidate list is 4, thespatial motion vector candidate at the specific neighboring block B2 isunavailable; wherein the candidate list is constructed based on apruning process, wherein the pruning process comprises comparing motioninformation between at least two spatial motion vector candidates toavoid identical spatial motion vector candidates; wherein theconstructing, based on the pruning process, the candidate list for thecurrent block includes checking an availability of a spatial motionvector candidate at a specific neighboring block A1, wherein thespecific neighboring block A1 is adjacent to a lower left corner to thecurrent block, the checking comprising: when the candidate list includesa spatial motion vector candidate at a specific neighboring block B1,wherein the specific neighboring block B1 is adjacent to a top rightcorner to the current block, comparing motion information between thespatial motion vector candidates at the specific neighboring block A1and the specific neighboring block B1, and determining that the spatialmotion vector candidate at the specific neighboring block A1 isunavailable, based on the comparing result indicates that the motioninformation of the spatial motion vector candidate at A1 is identical tothat at B1; wherein the constructing, based on the pruning process, thecandidate list for the current block includes checking an availabilityof a spatial motion vector candidate at a specific neighboring block B0,wherein the specific neighboring block B0 is at a top right corner ofthe current block, the checking comprising: when the candidate listincludes a spatial motion vector candidate at a specific neighboringblock B1, wherein the specific neighboring block B1 is adjacent to a topright corner to the current block, comparing motion information betweenthe spatial motion vector candidates at the specific neighboring blockB0 and the specific neighboring block B1; and determining that thespatial motion vector candidate at the specific neighboring block B0 isunavailable, based on the comparing result indicates that the motioninformation of the spatial motion vector candidate at B0 is identical tothat at B1; wherein the constructing, based on the pruning process, thecandidate list for the current block includes checking an availabilityof a spatial motion vector candidate at a specific neighboring block A0,wherein the specific neighboring block A0 is at a lower left corner ofthe current block, the checking comprising: when the candidate listincludes a spatial motion vector candidate at a specific neighboringblock A1, wherein the specific neighboring block A1 is adjacent to alower left corner to the current block, comparing motion informationbetween the spatial motion vector candidates at a specific neighboringblock A0 and the specific neighboring block A1; and determining that thespatial motion vector candidate at the specific neighboring block A0 isunavailable, based on the comparing result indicates that the motioninformation of the spatial motion vector candidate at A0 is identical tothat at A1; wherein checking the availability of the spatial motionvector candidate at the specific neighboring block B2 further includes:when the candidate list includes spatial motion vector candidates atspecific neighboring blocks A1 and B1, wherein the specific neighboringblock B1 is adjacent to a top right corner to the current block and thespecific neighboring block A1 is adjacent to a lower left corner to thecurrent block, comparing motion information between the spatial motionvector candidates at the specific neighboring block B2 and the specificneighboring blocks A1 and B1, and determining that the spatial motionvector candidate at the specific neighboring block B2 is unavailable,based on the comparing result indicates that the motion information ofthe spatial motion vector candidate at B2 is identical to that at A1 orB1.